Managing Gentoo - a study in quotes [LWN.net]

Managing Gentoo - a study in quotes

Posted Sep 1, 2006 15:25 UTC (Fri) by djmutex (subscriber, #12657)
In reply to: Managing Gentoo - a study in quotes by iabervon
Parent article: Managing Gentoo - a study in quotes

I second (third?) this as well. I've been running Gentoo on my home machine since Jan 2003, and it's the only Linux I haven't managed to break beyond repair within a few months.

With all binary distros I sooner or later ran into some upgrade problem that prevented them from starting and that wasn't trivial to fix, and with Gentoo, if such a problem ever occured, there were the always-helpful forums to my rescue.

Since then, I have used Gentoo on all my computers. That includes my laptop, my office machine, two public web and mail servers (with hardened Gentoo), and my new office machine will have it too.

So all I can say, it is the best operating system I know. For both desktop and server.

To me, if there's one thing where Gentoo clearly needs some steering, it's portage. From having read gentoo-dev for a few months now, this appears to be one of the main issues of contention as well (with the usual personality issues). Even though it's a great system, portage just doesn't scale, and even 2.1 is still unacceptably slow. Gentoo as a whole looks undecided to me about where to go from there.

(Log in to post comments)

Managing Gentoo - a study in quotes

Posted Sep 1, 2006 16:16 UTC (Fri) by iabervon (subscriber, #722) [Link]

All of the persistant problems I've had with Gentoo so far have been fixed by leaving it running the way it is for a day or two, syncing, and trying again.

I agree that portage needs work, but I think the main issue is that it needs to be able to simultaneously merge multiple updates (to deal with the case where the state before is fine, and the state after is fine, but there are conflicts preventing any series of individual steps that doesn't include removing a package in between; it only comes up on occasion, but, when it does, it's scary, since you have a period when your system doesn't have /bin/login or something) and it needs to have back pressure in the dependancy solver (e.g., new versions of package A require versions of package B which are masked; treat those new versions of package A as masked, and thus the less-new version of A is the newest acceptable; or new versions of glibc only work with the nptl USE flag, which is not set, so those versions should be treated as masked unless the USE flag gets set).

I do think that it needs the ability to sync only a single package, and it should do this automatically if trying to build it fails (I've had a number of days when version N is current for my middle-of-the-night sync, but N+1 is current and the files for N, which was badly broken, are gone in the morning when I try to install it; it'd be nice if portage would work this out without requiring a manual and full --sync). I find that the speed isn't bad if I sync from a nightly cron job, so it's done all of the slow and uninteractive stuff when I'm not waiting.

Oh, and today's quibble: glibc-2.4 depends not only on having a recent gcc, but on that gcc being the compiler used to build with. Yesterday, it built me gcc 4.1.0, and then aborted trying to build glibc-2.4 with the still-default gcc 3.3.x. Portage ought to know that, if you depend on a particular version of a slotted package, it needs to make sure that you actually use the selected version.