| |||||||||||||
|
| |||||||||||||
Managing Gentoo - a study in quotesManaging Gentoo - a study in quotesPosted Aug 31, 2006 14:54 UTC (Thu) by iabervon (subscriber, #722)Parent article: Managing Gentoo - a study in quotes
I find this all particularly odd because Gentoo's technical image is so decentralized. It seems almost like the end user should be able to select the Council with global USE flags or as a profile. Obviously, this isn't true, but the image that Gentoo presents to the user is of being a small project to develop package-manager-type programs, plus people who notice when desireable patches are available for the packages they maintain; sort of the Amazon Marketplace of distros, where your package actually comes from somebody else.
It would be interesting to have an article on how Gentoo's management structure officially works.
(Log in to post comments)
Managing Gentoo - a study in quotes Posted Aug 31, 2006 16:07 UTC (Thu) by dberkholz (subscriber, #23346) [Link] Here's the current structure: http://www.gentoo.org/proj/en/glep/glep-0039.html
Gentoo's only small if you consider 350+ developers small. It takes a lot of work to maintain a database of more than 10,000 packages, along with all of our documentation, infrastructure, and other miscellaneous projects such as the installer.
Managing Gentoo - a study in quotes Posted Aug 31, 2006 17:19 UTC (Thu) by g2boojum (subscriber, #152) [Link] > It would be interesting to have an article on how Gentoo's management> structure officially works.
The current (official) structure is:
Whether it works or not is (clearly) open for debate.
The previous management structure is documented in:
Managing Gentoo - a study in quotes Posted Sep 1, 2006 15:25 UTC (Fri) by djmutex (subscriber, #12657) [Link] 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.
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.
|
|
||||||||||||