* [gentoo-dev] Re: Request for Comment
2006-02-11 2:37 [gentoo-dev] Request for Comment Klaus-J. Wolf
2006-02-11 2:42 ` Dan Meltzer
@ 2006-02-11 5:41 ` Duncan
2006-02-11 17:02 ` John Mylchreest
2006-02-11 10:10 ` [gentoo-dev] " Simon Stelling
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Duncan @ 2006-02-11 5:41 UTC (permalink / raw
To: gentoo-dev
Klaus-J. Wolf posted <200602110337.25218.yanestra@seismic.de>, 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [gentoo-dev] Request for Comment
2006-02-11 2:37 [gentoo-dev] Request for Comment Klaus-J. Wolf
2006-02-11 2:42 ` Dan Meltzer
2006-02-11 5:41 ` [gentoo-dev] " Duncan
@ 2006-02-11 10:10 ` Simon Stelling
2006-02-11 14:38 ` Marius Mauch
2006-02-11 23:11 ` Benno Schulenberg
4 siblings, 0 replies; 10+ messages in thread
From: Simon Stelling @ 2006-02-11 10:10 UTC (permalink / raw
To: gentoo-dev
(I think it would be better if you could post the text on the list, so people
can easier cite the paragraphs they are referring to.)
> I cite one situation which has actually led to system destruction:
>
> I was in need of a certain version of a library. A the moment I installed it
> initially, this version was keyword masked for my architecture, since it was
> not thoroughly tested. It worked perfectly anyway. Since it was without
> issues, it became officially unmasked some time later and another version was
> introduced, which was keyword masked because it didn't work at all on my
> architecture. This one could be compiled, but really didn't work at all. Since
> I didn't observe the new version introductions all the time, a slightly
> careless world update gave me that version and left all programs depending on
> the library in a non-working state.
>
> After all it was my fault, but on a resonably maintained system you will
> always have a number of manually unmasked ebuilds, and you can't monitor them
> all the time.
This is why you should use exact versions in p.mask and p.unmask. If you do that
you only get the minimum of masked packages, leading to minimal borkage.
Now, over to the GLEP draft..
You make some very dangerous (partly wrong) assumptions in your GLEP. First of
all, there's the assumption that we have the capacity to maintain such a fine
graded masking scheme. We are currently mainly distinguishing between testing
~arch and stable arch. I can only speak for AMD64, but we have a currently ~100
packages that wait to go into the ~amd64 tree, 54 of them for longer than 30
days. Beside that, we have about 120 packages waiting to go into the stable
tree. Now, if you'd increase the number of masking "stages" from two to 10, I
can guarantee that this masking scheme would get completely useless.
But the far more critical assumption you make is this one:
You assume that once a package has been marked stable, it keeps beeing stable.
You simply can't treat every package individually. A package marked stable back
in 2004 with a status level -5 should be considered ultimatively stable if I
understand your proposal right. But then GCC 3.4 is marked stable too, and, oh,
look, it doesn't even compile!? Things depend on each other, in a very complex
fashion. Whenever some behaviour in one package is changed, it is likely to
break another one. Instead of giving us 10 different status levels, show us a
way to avoid such problems in general.
Part of the assumption above is also the fact that these keywords do not
consider the profile the user is using. A package might work great for one
profile but terribly break for another (deprecated) one.
You can apply the same idea to eclasses. Basically it all bails down to this:
Give me 10 environments and I give you 10 different ways to break the package.
Regards,
--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 10+ messages in thread