apt-get (was: Re: first release date)

[Rahul Siddharthan]

Michel Talon wrote:
>> what exactly is so good about apt-get ?
>> Anyways here is a first version:
>> http://www.splashground.de/~andy/dragonfly/apt-get
>>
>> IMO ports is so much above apt they shall copy it not vice versa.
>
>I concur with you. The most fashionable Linux distro at present among
>geeks is Gentoo which has copied the BSD ports system. 

Fashionable != reliable.  I tried gentoo for a while, twice in
three months I made the system unbootable because of a botched libc
upgrade.  (Such botches can happen with FreeBSD ports too but won't
render the system unbootable because the base system isn't packaged.)
I've been keeping my debian (originally knoppix) system up
to date for a year now with apt-get, there has never been the
slightest problem.  Even if I interrupt the process in the middle, it
recognises that and cleans up next time.  It's amazingly good stuff.

Others seem to agree: all the newbie-friendly linux distros -- 
Progeny, Corel/Xandros, Lindows -- are based on Debian, as is Knoppix, 
and apt-get is also used by Connectiva and (optionally) by Fedora.

Ports is nothing like apt, let alone "above" it.  Apt manages multiple
repositories cleanly, that's its biggest win in my opinion.  You can
install unofficial packages (with dependencies and all) by just adding
a line to sources.list; with FreeBSD ports it's essentially impossible
to do it cleanly.  

>Look at the
>problems one gets with portupgrade, exactly the same are to be found
>with apt-get.

What problems are these?  I know of only one problem with portupgrade,
the disruptive library upgrade (eg, bump up gettext to an incompatible
version and you have to upgrade 80% of your ports).  The problem is
compounded in portupgrade by the fact that most ports end up being
compiled from source (because up-to-date binary packages don't exist).

This problem exists in Debian but is mitigated by two things: (1) it's
based on binary packages, so it doesn't take all that long; and 
(2) they have a three-tier system of unstable -> testing -> stable, 
where packages move "downhill" to "testing" only after stabilising a bit 
and only when they won't be disruptive to existing packages, and the 
entire "testing" system becomes "stable" when it, well, stabilises. 
This would be overkill for DragonFly, and the VFS idea (maintaining
multiple versions on the same system) will solve this problem much
more cleanly.

Rahul