On Tue, Sep 11, 2007 at 08:34:38AM +0900, Lionel Bouton wrote:
> 
> > I just checked.  Compared with Debian's more than 18k packages (not sure
> > how many more -- I haven't checked lately) and FreeBSD's more than 17k
> > ports, it looks like Gentoo provides just over 11k.  I think that puts
> > Gentoo solidly in second place for Linux distributions, but well behind
> > FreeBSD.
> >   
> See the note about packages splitted in many subpackages in my reply to
> Fred. I was thinking of Debian and Ubuntu when writing it... IIRC I had
> to install around 10 packages on Ubuntu in March this year to get
> roughly the same result than emerge ruby... I must admit I wasn't happy
> about it especially as at the time Rails was installed with rubygems
> manually so all the missing deps where found with runtime failures :-(
> In the end Rails didn't even get to work correctly because of different
> loadpaths in the gems and the deb packaged libraries. In short the
> Ubuntu/Debian admin followed a Rails on Ubuntu tutorial and failed
> because making the system consistant was hard even for plain simple
> Rails. I sincerely hope Debian is better but I still have doubts (IIRC
> the Ubuntu packages were the original Debian ones without any Ubuntu patch).

In my experience, Debian is much better about making sure things like
that work.  Debian does tend to divide up some packages, of course, so
that you can get only the parts you actually want if you don't want the
whole shmear (like if you want Ruby and Rails, but not irb, for some
reason).  Source-based OSes get a little bit of a free pass on that sort
of thing (at least if they're well-managed) because you can configure
compilation to use, or not use, components you do or don't want via the
makefile, make configuration interface, or the software management system
itself in some cases -- without having to separate components into
separate packages.

Still . . . Debian (not Ubuntu) has a *tremendous* number of packages,
and not by any means simply because certain installable software options
are divided up into two or three packages where they might only be one
somewhere else.


> 
> At least the dependency hell on Debian is benign compared to Fedora. One
> time I managed to have eclipse installed on a slow Gentoo box faster
> than a colleague on a fast Fedora box without even trying... yum had to
> fetch around 70 packages for him while my configuration only generated
> 15-20 dependencies !

Dependency management is quite slick in Debian, in general.  APT is an
excellent tool.  The worst problems I've had with it were during a period
when it was contending with A) an uncharacteristic push to get a new
Stable release out the door "on time", B) the height of package
maintainer defections to Ubuntu, and C) probably something else that
escapes my memory at the moment, too.  That was about the time that I
findally found the motivation to give FreeBSD a more serious shot than I
had previously, too.

Having used YUM and APT back-to-back a fair bit, I think Fedora could
have done a lot better with a software management toolset choice.  I
can't help but wonder if Fedora's choice to go with YUM rather than the
APT-RPM that was becoming popular about that time had something to do
with a "not invented here" political issue, since APT as the canonical
DEB management tool was long seen as RPM's "competition".

A friend of mine actually benchmarked APT and YUM under a number of
different sets of conditions, and found that YUM takes something like
50-1000 times as long to complete install operations (a widely varying
difference, but some depressing numbers nonetheless).


> 
> On a positive note, it doesn't seem FreeBSD was chopped in so many
> pieces (at least for Ruby I only noticed a ruby18-doc that isn't counted
> in Gentoo but there anyway in the basic ruby ebuild).

FreeBSD doesn't tend to play silly buggers with software packaging, I've
noticed.  It's one of the things I like about it.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
John Kenneth Galbraith: "If all else fails, immortality can always be
assured through spectacular error."