Gentoo and stable ebuilds
I will start by presuming that you know about the Gentoo distribution of Linux and also about Gentoo’s ebuilds within the Portage package system. Let me also start by saying that I love Gentoo. I had been using RedHat since I started with Linux in 1997 migrated to Gentoo in September 2003 - and I’ve never looked back.
But the problem with Gentoo’s ebuilds right now is that they are inconsistant. For example, an ebuild for the new Mozilla Thunderbird 0.8 came out within 24 hours of the release. FlightGear 0.9.5 on the other hand was released July 29, 2004 and we’re still waiting for an ebuild. And for that matter, the ebuild for FlightGear 0.9.4 is still marked as unstable. These are two fairly extreme examples but you probably get the point.
Gentoo revolves about a group of volunteers, who like everyone else, has other things to do that more often than not take priority over Gentoo things. I’m not currently involved with Gentoo as a volunteer so some of what I am about to suggest may already be in place or simply may not be possible. But that said, here are my solutions to these things that I perceive to be problems.
I think that there enough people (who aren’t already on the Gentoo team) that can create ebuilds, that there should be no reason for there not to be an ebuild for the latest version of all existing packages with Portage. But, to maintain some stability obviously, ebuilds need to be reviewed. In a lot of cases, I think Gentoo developers cover multiple products and are busy with other aspects of their life. For that reason, I think that every package in Portage needs at least two people who share responsibility for that package, no matter how small or simple it is. In addition, every package should have a meta reviewer, a developer who is familiar and interested enough to ensure the ebuild is up to snuff and to add the ebuild to the CVS tree in the absense of the main two developers.
We also need a system within Gentoo to report that we have installed a package marked as stable and the degree to which it’s working, rated on a scale of 0 to 10, with 0 being it doesn’t work (and have reported a bug) and 10 being that it works perfectly and as expected. A system like this would serve several purposes; it would allow people to be notified when new unstable ebuilds are added to the system and it would allow people to see how others are fairing with the unstable builds.
In a lot of cases stable ebuilds appear within a few days of a package being released. This has resulted in me relying on using the portage system as a quasi replacement for Freshmeat and various project websites. I no longer needed to check for new releases as simply typing:
% emerge -upD world
would give me a list of what’s new. But, in some cases, this isn’t the case. To use FlightGear again as an example, version 0.9.4 of FlightGear was released on March 26, 2004. An ebuild for 0.9.4 arrived on April 2, 2004. That’s a reasonable delay, especially given that FlightGear relies on SimGear and in this case a new version of SimGear (and thus a new ebuild for that also) was also required. The bad part is that as of today 0.9.4 still isn’t marked as stable, and worse yet, 0.9.5 was released on July 29, 2004. And the worst of it all is that 0.9.6 is due to be released in the coming weeks. I built 0.9.4 on July 15th, when I happened to surf to flightgear.org to see when a new version was going to be released. Up until that point I had been running 0.9.3 and had no idea that 0.9.4 had even been released. Imagine my surprise to see that a new version of FlightGear had come out over 2 months prior. Despite the fact that the 0.9.4 ebuild was marked as unstable, I built 0.9.4 and have been running it with no problems whatsoever.
This is where that ebuild monitoring system would be handy. I envision this being set up similar to RedHat’s RetHat Network, where you registered each system and you could go to a website to see which systems needed what packages updated. That in itself would be a wonderful idea for Gentoo - instead of emerging each day so I could see what has changed I could simply log on to a website and see what packages that I have installed on my boxes have been updated. But more importantly, I would hopefully be able to see what unstable packages are available for my system, and what degree of success others are having with those packages. I’m not sure how best to implement a system like this but I’m going to look into it… along with the six b-zillion other ideas I have.
Thu, 16 Sep 2004 19:39 Posted in Linux
