Klaus-J. Wolf posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 11 Feb 2006 03:37:25 +0100:
> Would you please discuss a GLEP draft, which I believe it might improve > the usability of Gentoo? > > Text at: > > http://www.seismic.de/gentoo/gentoo_mask_proposal.html I'm just a user, not a dev, myself, so take this as you will, but the general idea is the same sort of ultra-stable enterprise stability targeted system that comes up for discussion here every so often, and already has various levels of workable and not-quite-so-workable proposals floating around. This particular one's in the not-quite-so-workable camp, mainly because (1) it doesn't work /with/ portage or the way things work now, but against it, in a number of ways (2) it doesn't consider the different speeds at which different packages move (this is the big one, there's likely never /been/ ten or even five versions of some packages that have existed since there /was/ a Gentoo), and (3) it doesn't really consider the way devs work. Point of fact, it's particularly from a user perspective, not understanding a /lot/ about the "supply" side of the distribution mechanism, only the /user/ or /demand/ side. I'm specifically /not/ saying I could do better, but... take a look at the archives for this list, read some of the previous proposals and the discussion they generated, and /then/ formulate a proposal, based on what has been already hashed out and found /not/ to work, vs what there's been little disagreement about, only it just hasn't been fully implemented, yet. As for specifics... Most of the issues you mention are already addressed with the current system, or aren't practically addressable anyway, with your proposal either asking the impossible (ten versions of something there may have only been two or three releases of in the entire time Gentoo has been around), or not directly addressing the problem in the first place) what works for most systems will inevitably fail in some corner case, which will either never be traced, or ends up being related either to a specific mix of packages, or to a specific configuration at the problem side -- one not tested for as it has never occurred to anyone in the pre-stable release period, because nobody matched those conditions. This is, BTW, exactly the same reason that invariably, a new kernel release brings a new round of bugs that weren't caught in the rc and pre-release testing -- no one had that specific configuration to test on -- so it's not just a Gentoo issue. BTW, it's also not an open source issue, as the service-pack releases attest in the proprietary market -- and they get /paid/ to make sure it works. There's actually three levels of masking, four if you include being available in an overlay on someone's dev-space somewhere but not yet in the tree as a sort of super-masked state, in addition to the unmasked state, and one of the recent Enterprise Gentoo proposals suggested a fourth/fifth, a +arch (super-stable), tho that hasn't yet been implemented, and may or may not ever get to that point. The current levels: * (not yet in the tree) * In the tree, with no keywords, or more precisely -*. This signifies a "work in progress" not yet considered by the Gentoo maintainer to be ready for significant deployment, even at a testing level. Some of these are there by popular demand for the convenience of the users and will /never/ get further, nor are they considered supported by Gentoo. Certain periodic CVS snapshots can fall into this category. These are often packages that are considered unstable/testing/alpha/beta, non-release quality, upstream, as well. * Hard-masked. These ebuilds normally appear in the package.masked file at the base of the profiles tree, with a reason given there as to why they are in this hard-masked state. It can range from pre-release upstream versions of a package that will ultimately have a stable release (the snapshots/betas/rcs of xorg-modular and GNOME and KDE come to mind), to packages masked before removal due to security issues or because they simply no longer work in a changing world, and upstream is abandoned, so no new versions are appearing (the GLSA announced packages, and the "Last rites for <pkg> announcements here on this list, signify packages normally hard-masked, then removed). * ~arch masked as candidate for stable. ~arch, where arch can be x86, amd64, ppc, etc, indicates a package normally considered stable or at least release candidate level upstream, where the ebuild /should/ work for /most/ Gentoo users as is, and there are no known dangerous bugs left. These are candidates for going stable, after some period of testing in ~arch with no bugs. Note that the archs themselves (save for x86 until recently) ultimately determine when and whether a package goes stable, and the maintainer usually signals his willingness for this to happen by stabilizing on his own arch(s) when he feels comfortable doing so. There's no hard and fast rule for when something goes stable, but the general rule of thumb is after 30 days in ~arch and with no open bugs. Thus, ~arch indicates a package considered stable upstream, and ready for testing to be stable on Gentoo. The package should be stable, but the ebuild, the way the package interacts with Gentoo specifically, might not be, is another way to put it. The problem you apparently had, was that you apparently did the equivalent of adding the package in question to /etc/portage/package.unmask and/or /etc/portage/package.keywords, with the appropriate ~arch keyword, without confining it to a specific version. It has been possible since portage 2.0.51 at least to make such a listing apply to a specific version, such that no others will be unmasked. If you want to apply it to all versions of the package, running the latest ~arch keyworded version of the package for your arch rather than the latest stable version, that's possible, and what you apparently did, by simply leaving out or wildcarding the version specifier, but if you want only a specific version, that too is possible, and has been for some time, and should have been what you did, if you were in doubt about future ~arch versions. The point is, you don't /have/ to monitor your manually unmasked ebuilds, as if the version is properly specified, portage won't upgrade you automatically in any case. Thus, that can't be justification for changes to the current system, as that feature is already available, and indeed, widely used as intended. As mentioned, your proposal is unworkable in present form anyway (not a big deal, no GLEP would be at this stage), because there simply haven't been ten versions available of many packages, and of the ones where there have been, there are very very seldom ten package versions still workable on a current system, for any given arch. As briefly mentioned above, there /has/, however, been a proposal for a "super-stable" package marker, +arch. This package would likely no longer be maintained by the regular Gentoo maintainer, as backporting security changes and the like to something that old is something many maintainers would resist, preferring instead to simply remove the vulnerable or unworkable package from the tree. Rather, the new Gentoo Enterprise project, presumably containing devs interested in the often dreary work of backporting and maintenance of an Enterprise-stable distribution, would maintain these builds. The fact is, there are a number of devs intensely interested in such a program, to the point they've been known to complain about Gentoo having no visible progress, because this one thing they are so interested in hasn't occurred. However, apparently, these devs either don't have /enough/ interest, or don't have /enough/ time (they are, after all, volunteers), or there simply aren't /enough/ such devs, or more likely a mixture of the above, for this to have been seen thru to completion at this point. The idea of an Enterprise Gentoo that supports packages well past the time when they are no longer viable in the standard Gentoo portage tree, remains just that, an idea, at this point. There has been work done on it, but you'll have to pull the archives and look up the devs supporting the idea, to see what the current status is. So... what it all comes down to, if you are seriously interested in something along these lines, is checking the list archives to see what past proposals have been, their strengths and the elements of them that were shot down, and the people pushing them, then contacting them, to see what you can contribute toward bringing such a proposal to pass. Don't go away if you are serious about changes and willing to contribute to see them accomplished -- Gentoo /needs/ folks like you that are interested, but do some research and get in contact with the devs with similar interests, and see what you can do, then as part of /that/ group, come back when the proposal is ready for further discussion, having addressed the known issues as much as possible, and possibly to be adopted. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
