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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
