Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 May 2007 14:37:44 +0200
From:      Michel Talon <talon@lpthe.jussieu.fr>
To:        freebsd-hackers@freebsd.org
Subject:   Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
Message-ID:  <20070512123744.GA14586@lpthe.jussieu.fr>

next in thread | raw e-mail | index | archive | help
Ivan Voras wrote:

> In my (limited) experience, this sort of task should not depend much on
> the speed of the language. The most CPU-intensive task portupgrade does
> is resolving dependencies, and on a running system this is a DAG forest
> of about 500 nodes. I know portupgrade has some highly unoptimal code in
> it (if I understand the code correctly, there's a brute force check for
> cyclic dependancies in it!), but still, in itself, I think the choice of
> Ruby isn't performance-critical.

If i remember well, portupgrade uses a reasonable algorithm to sort the
DAG in question. But from time to time, it runs 
make depends 
or something of the sort in some ports directory, and this is the slow
step which kills any package manager whatsoever, be it written in super
fast C or superslow ruby. This is because as soon as you run "make" in
such a directory it has to read and interpret the 4000 lines file
bsd.ports.mk. This takes 1/10 s on my old laptop and perhaps 5 times
faster on a powerful machine.

Add to that the natural slowness of ruby, the fact that portupgrade
constantly does queries in the Berkeley pkgdb.db, portsdb.db etc. while
it could cache the whole content in memory without any problem in modern
machines, and you have something which is slow as a mollasse.

Then you have more structural problems such as the "guessing facilities"
of portupgrade, which aim at guessing what is the new origin of a port
whose old origin has disappeared. To do that it counts similarities on
names, adds some snake oil and other satanic ingredients and comes out
with a guess. For some time i was impressed by the exactness of these
guesses, but recently i have seen incredibly hilarious results. As a
consequence i think that portupgrade is a completely inadequate tool
to maintain a FreeBSD machine in an automated way in spite of the 
remarkable insight which is coded in it, and that Debian like systems
run circles around FreeBSD for ease of maintenance. Yes the FreeBSD
system is very good for initial installation of software and the
flexibility it allows to do that. But it sucks completely as soon as one
wants to upgrade stuff. The best way by far is wipe out every port and
reinstall. This will take 1/3 of the time to run portupgrade -a and
with a much better chance of success and coherency at the end.

Note that these innocent looking facts have little consequences:
FreeBSD was in position 11 on Distrowatch in 2005, it is now in position
17 and falling like a brick. 


-- 

Michel TALON




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070512123744.GA14586>