1 |
Klaus-J. Wolf posted <200602110337.25218.yanestra@×××××××.de>, excerpted |
2 |
below, on Sat, 11 Feb 2006 03:37:25 +0100: |
3 |
|
4 |
> Would you please discuss a GLEP draft, which I believe it might improve |
5 |
> the usability of Gentoo? |
6 |
> |
7 |
> Text at: |
8 |
> |
9 |
> http://www.seismic.de/gentoo/gentoo_mask_proposal.html |
10 |
|
11 |
I'm just a user, not a dev, myself, so take this as you will, but the |
12 |
general idea is the same sort of ultra-stable enterprise stability |
13 |
targeted system that comes up for discussion here every so often, and |
14 |
already has various levels of workable and not-quite-so-workable proposals |
15 |
floating around. This particular one's in the not-quite-so-workable camp, |
16 |
mainly because (1) it doesn't work /with/ portage or the way things work |
17 |
now, but against it, in a number of ways (2) it doesn't consider the |
18 |
different speeds at which different packages move (this is the big one, |
19 |
there's likely never /been/ ten or even five versions of some packages |
20 |
that have existed since there /was/ a Gentoo), and (3) it doesn't really |
21 |
consider the way devs work. Point of fact, it's particularly from a user |
22 |
perspective, not understanding a /lot/ about the "supply" side of the |
23 |
distribution mechanism, only the /user/ or /demand/ side. |
24 |
|
25 |
I'm specifically /not/ saying I could do better, but... take a look at the |
26 |
archives for this list, read some of the previous proposals and the |
27 |
discussion they generated, and /then/ formulate a proposal, based on what |
28 |
has been already hashed out and found /not/ to work, vs what there's been |
29 |
little disagreement about, only it just hasn't been fully implemented, yet. |
30 |
|
31 |
As for specifics... Most of the issues you mention are already addressed |
32 |
with the current system, or aren't practically addressable anyway, with |
33 |
your proposal either asking the impossible (ten versions of something |
34 |
there may have only been two or three releases of in the entire time |
35 |
Gentoo has been around), or not directly addressing the problem in the |
36 |
first place) what works for most systems will inevitably fail in some |
37 |
corner case, which will either never be traced, or ends up being related |
38 |
either to a specific mix of packages, or to a specific configuration at |
39 |
the problem side -- one not tested for as it has never occurred to anyone |
40 |
in the pre-stable release period, because nobody matched those conditions. |
41 |
This is, BTW, exactly the same reason that invariably, a new kernel |
42 |
release brings a new round of bugs that weren't caught in the rc and |
43 |
pre-release testing -- no one had that specific configuration to test on |
44 |
-- so it's not just a Gentoo issue. BTW, it's also not an open source |
45 |
issue, as the service-pack releases attest in the proprietary market -- |
46 |
and they get /paid/ to make sure it works. |
47 |
|
48 |
There's actually three levels of masking, four if you include being |
49 |
available in an overlay on someone's dev-space somewhere but not yet in |
50 |
the tree as a sort of super-masked state, in addition to the unmasked |
51 |
state, and one of the recent Enterprise Gentoo proposals suggested a |
52 |
fourth/fifth, a +arch (super-stable), tho that hasn't yet been |
53 |
implemented, and may or may not ever get to that point. |
54 |
|
55 |
The current levels: |
56 |
|
57 |
* (not yet in the tree) |
58 |
|
59 |
* In the tree, with no keywords, or more precisely -*. This signifies a |
60 |
"work in progress" not yet considered by the Gentoo maintainer to be ready |
61 |
for significant deployment, even at a testing level. Some of these are |
62 |
there by popular demand for the convenience of the users and will /never/ |
63 |
get further, nor are they considered supported by Gentoo. Certain periodic |
64 |
CVS snapshots can fall into this category. These are often packages that |
65 |
are considered unstable/testing/alpha/beta, non-release quality, upstream, |
66 |
as well. |
67 |
|
68 |
* Hard-masked. These ebuilds normally appear in the package.masked file |
69 |
at the base of the profiles tree, with a reason given there as to why they |
70 |
are in this hard-masked state. It can range from pre-release upstream |
71 |
versions of a package that will ultimately have a stable release (the |
72 |
snapshots/betas/rcs of xorg-modular and GNOME and KDE come to mind), to |
73 |
packages masked before removal due to security issues or because they |
74 |
simply no longer work in a changing world, and upstream is abandoned, so |
75 |
no new versions are appearing (the GLSA announced packages, and the "Last |
76 |
rites for <pkg> announcements here on this list, signify packages normally |
77 |
hard-masked, then removed). |
78 |
|
79 |
* ~arch masked as candidate for stable. ~arch, where arch can be x86, |
80 |
amd64, ppc, etc, indicates a package normally considered stable or at |
81 |
least release candidate level upstream, where the ebuild /should/ work for |
82 |
/most/ Gentoo users as is, and there are no known dangerous bugs left. |
83 |
These are candidates for going stable, after some period of testing in |
84 |
~arch with no bugs. Note that the archs themselves (save for x86 until |
85 |
recently) ultimately determine when and whether a package goes stable, and |
86 |
the maintainer usually signals his willingness for this to happen by |
87 |
stabilizing on his own arch(s) when he feels comfortable doing so. |
88 |
There's no hard and fast rule for when something goes stable, but the |
89 |
general rule of thumb is after 30 days in ~arch and with no open bugs. |
90 |
Thus, ~arch indicates a package considered stable upstream, and ready for |
91 |
testing to be stable on Gentoo. The package should be stable, but the |
92 |
ebuild, the way the package interacts with Gentoo specifically, might not |
93 |
be, is another way to put it. |
94 |
|
95 |
The problem you apparently had, was that you apparently did the equivalent |
96 |
of adding the package in question to /etc/portage/package.unmask and/or |
97 |
/etc/portage/package.keywords, with the appropriate ~arch keyword, |
98 |
without confining it to a specific version. It has been possible since |
99 |
portage 2.0.51 at least to make such a listing apply to a specific |
100 |
version, such that no others will be unmasked. If you want to apply it to |
101 |
all versions of the package, running the latest ~arch keyworded version |
102 |
of the package for your arch rather than the latest stable version, that's |
103 |
possible, and what you apparently did, by simply leaving out or |
104 |
wildcarding the version specifier, but if you want only a specific |
105 |
version, that too is possible, and has been for some time, and should have |
106 |
been what you did, if you were in doubt about future ~arch versions. |
107 |
|
108 |
The point is, you don't /have/ to monitor your manually unmasked ebuilds, |
109 |
as if the version is properly specified, portage won't upgrade you |
110 |
automatically in any case. Thus, that can't be justification for changes |
111 |
to the current system, as that feature is already available, and indeed, |
112 |
widely used as intended. |
113 |
|
114 |
As mentioned, your proposal is unworkable in present form anyway (not a |
115 |
big deal, no GLEP would be at this stage), because there simply haven't |
116 |
been ten versions available of many packages, and of the ones where there |
117 |
have been, there are very very seldom ten package versions still workable |
118 |
on a current system, for any given arch. |
119 |
|
120 |
As briefly mentioned above, there /has/, however, been a proposal for a |
121 |
"super-stable" package marker, +arch. This package would likely no longer |
122 |
be maintained by the regular Gentoo maintainer, as backporting security |
123 |
changes and the like to something that old is something many maintainers |
124 |
would resist, preferring instead to simply remove the vulnerable or |
125 |
unworkable package from the tree. Rather, the new Gentoo Enterprise |
126 |
project, presumably containing devs interested in the often dreary work of |
127 |
backporting and maintenance of an Enterprise-stable distribution, would |
128 |
maintain these builds. The fact is, there are a number of devs intensely |
129 |
interested in such a program, to the point they've been known to complain |
130 |
about Gentoo having no visible progress, because this one thing they are |
131 |
so interested in hasn't occurred. However, apparently, these devs either |
132 |
don't have /enough/ interest, or don't have /enough/ time (they are, |
133 |
after all, volunteers), or there simply aren't /enough/ such devs, or more |
134 |
likely a mixture of the above, for this to have been seen thru to |
135 |
completion at this point. The idea of an Enterprise Gentoo that supports |
136 |
packages well past the time when they are no longer viable in the standard |
137 |
Gentoo portage tree, remains just that, an idea, at this point. There has |
138 |
been work done on it, but you'll have to pull the archives and look up the |
139 |
devs supporting the idea, to see what the current status is. |
140 |
|
141 |
So... what it all comes down to, if you are seriously interested in |
142 |
something along these lines, is checking the list archives to see what |
143 |
past proposals have been, their strengths and the elements of them that |
144 |
were shot down, and the people pushing them, then contacting them, to see |
145 |
what you can contribute toward bringing such a proposal to pass. Don't go |
146 |
away if you are serious about changes and willing to contribute to see |
147 |
them accomplished -- Gentoo /needs/ folks like you that are interested, |
148 |
but do some research and get in contact with the devs with similar |
149 |
interests, and see what you can do, then as part of /that/ group, come |
150 |
back when the proposal is ready for further discussion, having addressed |
151 |
the known issues as much as possible, and possibly to be adopted. |
152 |
|
153 |
-- |
154 |
Duncan - List replies preferred. No HTML msgs. |
155 |
"Every nonfree program has a lord, a master -- |
156 |
and if you use the program, he is your master." Richard Stallman in |
157 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
158 |
|
159 |
|
160 |
-- |
161 |
gentoo-dev@g.o mailing list |