View mode: basic / threaded / horizontal-split · Log in · Help
February 19, 2013
Re: The DUB package manager
On Monday, 18 February 2013 at 23:16:11 UTC, Nick Sabalausky 
wrote:
> http://cran.r-project.org/bin/linux/ubuntu/README.html
>
> Look at all that idiotic bullshit the users have to deal with 
> just for something that *could* have been a trivial 
> download/extract/run

It is simple, rational and I'll take it any day over 
download/extract/run idiom. Actually, I stopped installing 
anything without making a package before a long time ago. Other 
for Windows, of course, but, oh well, it is Windows. You sound 
biased.

> Secondly, where do you get that crazy idea that all end-users 
> only
> ever have one OS to deal with? ATM, I've got a couple windows 
> machines,
> a kubuntu desktop (old), and a debian 6 server. And that's not 
> counting
> VMs.

It is possible, but if you have a single language to deal with 
and a lot of OSes, your cases is probably a minority and few OSes 
with lot of languages are more relevant. I use 4 OSes in daily 
workflow too and I honestly can't imagine how can you use one 
without learning package manager in details anyway. Sorry, but is 
sounds completely ignorant.

> Other people have even more than that, and it doesn't help 
> anyone to
> have a totally different set of instructions for doing the same
> damn thing each one. *I* can install any version of DMD I want 
> on any
> of my systems by doing this:
>
> dvm install 2.0xx

And it is one more command to know as your supposed to know your 
package manager _anyway_. It is a damn first thing to learn about 
your distro.

> And finally, there's two types of users here, lib users and app 
> users:

I am speaking about dependencies here. They naturally leak from 
build system to distribution package. And if you think that large 
HDDs is a reason to package boost libs for hundreds of times, 
than I need to thank very same fucked up logic for having Core i7 
sometimes behave as slow as 10 year old Celeron on trivial 
applications.

P.S. gems are Ruby, not Python
February 19, 2013
Re: The DUB package manager
On Tuesday, 19 February 2013 at 00:08:40 UTC, Nick Sabalausky 
wrote:
> You can't really do anything like
> "apt-get install http://example.com/foo/bar-2.7" or "apt-get 
> install
> ./private-package-that-joe-sent-me-via-email".

You can. Debian is weird though because it is done via dpkg, not 
apt-get.
In Arch it is as simple to "pacman -U package-file" vs "pacman -S 
name-in-repo".
February 19, 2013
Re: The DUB package manager
On 2013-02-19 08:19, Dicebot wrote:

> You can. Debian is weird though because it is done via dpkg, not apt-get.
> In Arch it is as simple to "pacman -U package-file" vs "pacman -S
> name-in-repo".

Isn't apt-get built on top of dpkg or something like that?

-- 
/Jacob Carlborg
February 19, 2013
Re: The DUB package manager
On Tuesday, 19 February 2013 at 08:34:13 UTC, Jacob Carlborg 
wrote:
> On 2013-02-19 08:19, Dicebot wrote:
>
>> You can. Debian is weird though because it is done via dpkg, 
>> not apt-get.
>> In Arch it is as simple to "pacman -U package-file" vs "pacman 
>> -S
>> name-in-repo".
>
> Isn't apt-get built on top of dpkg or something like that?

It is. AFAIK apt-get is dpkg + getting packages via repo sources. 
But last time I have been searching, found no way to proxy dpkg 
call to install local package via apt-get which felt a bit weird. 
Probably my failure at searching though.
February 19, 2013
Re: The DUB package manager
On Tue, 19 Feb 2013 08:15:16 +0100
"Dicebot" <m.strashun@gmail.com> wrote:

> On Monday, 18 February 2013 at 23:16:11 UTC, Nick Sabalausky 
> wrote:
> > 
> > You sound biased.
> 

So do you.

There, that was constructive ;)

> It is possible, but if you have a single language to deal with 
> and a lot of OSes, your cases is probably a minority and few OSes 
> with lot of languages are more relevant. I use 4 OSes in daily 
> workflow too and I honestly can't imagine how can you use one 
> without learning package manager in details anyway. Sorry, but is 
> sounds completely ignorant.
> 
> > Other people have even more than that, and it doesn't help 
> > anyone to
> > have a totally different set of instructions for doing the same
> > damn thing each one. *I* can install any version of DMD I want 
> > on any
> > of my systems by doing this:
> >
> > dvm install 2.0xx
> 
> And it is one more command to know as your supposed to know your 
> package manager _anyway_. It is a damn first thing to learn about 
> your distro.
> 

Don't twist my words around. I never said anything about not learning
the OS package manager.

The issue is, if I'm going to do the same thing on multiple systems,
there's no reason it can't be doable the same way, and there's no
benefit to having it be completely different.

So yea, I could install DMD, for example, a totally different way on
different systems, but why should I when I can just do "dvm install
xxxxx" on *all* the systems?

And to top it off, imagine trying to do that as part of a bigger
script. I could write totally different scripts for each different
system just to do the same stupid thing, or one big script with tons of
platform-specific branches, or instead, I could use lanaguage-oriented
stuff like DVM/Dub/etc, avoid OS-specific stuff, and use the same
single script everywhere. Yea, how horrible.

Why do you prefer making extra work for yourself? Some puritanical
ideal of "If I'm on x OS I *have* to use the stuff that only
works there"? And don't tell me it's because you don't want to have
to learn a few extra trivial commands, because you're doing *plenty* of
complaining here about how completely ridiculous you think it is to
avoid learning a few more easy commands. (Nevermind that you're also the
only one who's actually objected to having to learn commands, in the
same post nonetheless.)


> And if you think that large 
> HDDs is a reason to package boost libs for hundreds of times, 
> than I need to thank very same fucked up logic for having Core i7 
> sometimes behave as slow as 10 year old Celeron on trivial 
> applications.

If you're just going to resort to obvious hyperbole, there's no point
in dealing with you.

> 
> P.S. gems are Ruby, not Python

Whatever python's package manager is called. It's been awhile since
I touched it, or Python or Ruby.
February 19, 2013
Re: The DUB package manager
On 02/19/2013 04:18 AM, Dicebot wrote:
> On Tuesday, 19 February 2013 at 08:34:13 UTC, Jacob Carlborg wrote:
>> On 2013-02-19 08:19, Dicebot wrote:
>>
>>> You can. Debian is weird though because it is done via dpkg, not
>>> apt-get.
>>> In Arch it is as simple to "pacman -U package-file" vs "pacman -S
>>> name-in-repo".
>>
>> Isn't apt-get built on top of dpkg or something like that?
>
> It is. AFAIK apt-get is dpkg + getting packages via repo sources. But
> last time I have been searching, found no way to proxy dpkg call to
> install local package via apt-get which felt a bit weird. Probably my
> failure at searching though.

In Red Hat & Fedoraland, it's a somewhat similar situation. RPMs are 
(usually) installed with the rpm command:
rpm -I dmd-2.062-0.fedora.x86_64.rpm
but yum (also, I believe, dnf for Fedora 18 users) can also install 
them, and do dependency checking:
yum install dmd-2.062-0.fedora.x86_64.rpm
February 20, 2013
Re: The DUB package manager
On Tuesday, 19 February 2013 at 00:53:07 UTC, Nick Sabalausky 
wrote:
> Admittedly, most of my linux experience (an unix in general) is
> Debian-derived stuff. (And a little bit of Mandrake from way 
> back when
> it was still called Mandrake, but that's not exactly relevant
> experience anymore ;) )

I was hooked on Ubuntu myself, until they began getting all
"MUST_CLONE_MACOSX", "MUST_TAKE_CONTROL_AWAY_FROM_USER" on 
everyone's ass (around the versions 8/9, I think). Tried a lot of 
different distros, eventually
landed with Arch. I think it's just the right mixture of 
convenience and customizability.

> Although I'll probably wait until the
> rumblings I've heard about efforts to make it easier to set up 
> start
> bearing fruit - I've been pretty much scarred for life on any 
> sort of
> manual configuring of X11. ;)

I'll treat that as two seperate points :)
(1) Setup Arch from install medium to first login:
That is unpleasant work, sadly. There once was something called 
AIF (Arch installation framework), which was an ncurses-graphical 
installer; it was good, but old and iirc barely maintained. 
Eventually they devs apparently decided to drop it and only ship 
a couple of scripts, that were easier to maintain and as far as I 
know they have not made any plans public where they would do more 
than provide these scripts. Point being, don't expect this part 
to get easier any time soon, it probably won't, so I'd suggest 
not tying the trying Archlinux out part to that problem.
On the other hand the Archlinux wiki (wiki.archlinux.org) has an 
excellent Beginner's guide and said scripts are fairly easy to 
use and remember, so after the second time you can usually do an 
Arch installation faster than the auto-installer of other distros 
(only possible because the Arch base system so very small, of 
course).

(2) X11 setup: Why would you want to configure X11 manually? 
"sudo pacman -S xorg-server xorg-xinit xf86-input-evdev 
xorg-video-(ati/intel/nouveau)", then install your desktop 
environment, e.g. "sudo pacman -S enlightenment17", copy the 
skeleton xinitrc file "cp /etc/skel/.xinitrc ~/" and change the 
exec line to your desktop environment, e.g. "exec 
enlightenment_start". Done. Now "startx" will give you your fully 
functional desktop environment, no need for any xorg.confs, X11 
configures itself automatically. Usually the only reason for an 
xorg.conf is when using the proprietary nvidia/ati drivers, but 
the Arch wiki has lenghtly (well-written) articles regarding 
those.

>
> In any case though, there still remains the problem that 
> OS-level
> package managers are more or less OS-specific. Something like 
> 0install
> sounds great, although I admit that I've been aware of it for 
> years
> and still have yet to actually try it.

I'm not familiar with 0install myself and the truth is I probably 
never will look at it - unless it can integrate with pacman, that 
is - I've simply grown to dependent on the convenience of pacman 
to try anything else :)
Anyway, I didn't want to put more oil in the fire of the 
OS-specific-language-independent-package-manager vs. 
language-specific-OS-independent-package manager debate (because 
frankly, I can't contribute much in that area, all I want is a 
package manager that simply works, be it OS or language specific, 
I really don't care as long as it just gets the job done right - 
one of the reasons I'm happy with pacman btw.), I just wanted to 
point out that not all OS-package-managers are evil. Sorry for 
dragging you slightly off-topic for so long^^
February 20, 2013
Re: The DUB package manager
On Wed, 20 Feb 2013 03:30:15 +0100
"Moritz Maxeiner" <moritz@ucworks.org> wrote:

> On Tuesday, 19 February 2013 at 00:53:07 UTC, Nick Sabalausky 
> wrote:
> > Admittedly, most of my linux experience (an unix in general) is
> > Debian-derived stuff. (And a little bit of Mandrake from way 
> > back when
> > it was still called Mandrake, but that's not exactly relevant
> > experience anymore ;) )
> 
> I was hooked on Ubuntu myself, until they began getting all
> "MUST_CLONE_MACOSX", "MUST_TAKE_CONTROL_AWAY_FROM_USER" on 
> everyone's ass (around the versions 8/9, I think).

Yea, same thing here. And I found the help from their ticket support
people to be...irrational.

Incidentally, the "MUST_CLONE_MACOSX",
"MUST_TAKE_CONTROL_AWAY_FROM_USER" just happen to also be the exact same
reasons I'm fed up with all forms of Windows post-XP. I'll never
understand why so many people have been so obsessed with cloning an OS
that's never even managed to reach double-digit market share. It's like
trying to clone the Ford Edsel: Why? Even if some people like it,
they'll just use the real thing anyway.

With Linux, when I outgrew Ubuntu I went upstream to Debian. Seemed the
most sensible choice given their close relationship and my Ubuntu
familiarity. I've had my eye on Mint, but, I dunno, it seems a little
too "downstream". And like I said, I'm starting to keep an eye on Arch
now too.

> 
> I'll treat that as two seperate points :)
> (1) Setup Arch from install medium to first login:[...]
> 
> (2) X11 setup: Why would you want to configure X11 manually? 
> "sudo pacman -S xorg-server xorg-xinit xf86-input-evdev 
> xorg-video-(ati/intel/nouveau)", then install your desktop 
> environment, e.g. "sudo pacman -S enlightenment17", copy the 
> skeleton xinitrc file "cp /etc/skel/.xinitrc ~/" and change the 
> exec line to your desktop environment, e.g. "exec 
> enlightenment_start". Done. Now "startx" will give you your fully 
> functional desktop environment, no need for any xorg.confs, X11 
> configures itself automatically. Usually the only reason for an 
> xorg.conf is when using the proprietary nvidia/ati drivers, but 
> the Arch wiki has lenghtly (well-written) articles regarding 
> those.

Ahh, thanks for all the info :)

As for the X11 stuff, that's still more manual than I'd like when it
comes to X11. (Like I said, I've had *BIG* problems dealing directly
with X11 in the past.) But I may give it a try. I'm sure it's improved
since the nightmares I had with it back around 2001/2002, but I
still worry *how* much improved... Heck, I've even had X11 problems as
recently as Ubuntu 10.


> 
> I'm not familiar with 0install myself and the truth is I probably 
> never will look at it - unless it can integrate with pacman, that 
> is - I've simply grown to dependent on the convenience of pacman 
> to try anything else :)
> Anyway, I didn't want to put more oil in the fire of the 
> OS-specific-language-independent-package-manager vs. 
> language-specific-OS-independent-package manager debate (because 
> frankly, I can't contribute much in that area, all I want is a 
> package manager that simply works, be it OS or language specific, 
> I really don't care as long as it just gets the job done right - 
> one of the reasons I'm happy with pacman btw.), I just wanted to 
> point out that not all OS-package-managers are evil. Sorry for 
> dragging you slightly off-topic for so long^^


No prob :) But I don't think OS-package-managers are evil (like I've
said, I like "apt-get install" *when it works*). It's just that I
think it's patently absurd when people claim that OS-package-managers
are the *only* good way to go and that there's no good legitimate
purpose for language-based OS-independent stuff. As long as they're
OS-dependent there will always be legitimate reasons for
alternatives.
February 20, 2013
Re: The DUB package manager
On Wednesday, 20 February 2013 at 03:52:12 UTC, Nick Sabalausky 
wrote:
> No prob :) But I don't think OS-package-managers are evil (like 
> I've
> said, I like "apt-get install" *when it works*). It's just that 
> I
> think it's patently absurd when people claim that 
> OS-package-managers
> are the *only* good way to go and that there's no good 
> legitimate
> purpose for language-based OS-independent stuff. As long as 
> they're
> OS-dependent there will always be legitimate reasons for
> alternatives.

Aptitude isn't really OS depend
February 20, 2013
Re: The DUB package manager
On Wednesday, 20 February 2013 at 03:52:12 UTC, Nick Sabalausky 
wrote:
> No prob :) But I don't think OS-package-managers are evil (like 
> I've
> said, I like "apt-get install" *when it works*). It's just that 
> I
> think it's patently absurd when people claim that 
> OS-package-managers
> are the *only* good way to go and that there's no good 
> legitimate
> purpose for language-based OS-independent stuff. As long as 
> they're
> OS-dependent there will always be legitimate reasons for
> alternatives.

Aptitude isn't really OS dependant. Just debian provide linux and 
BSD flavors, and it is used in many other distros.

Same goes for many other package managers.

The multiplication of package manager always seemed to me like a 
huge waste of resources.
7 8 9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home