1 |
> A few weeks back I filed a bug (since closed, but not resolved to my |
2 |
> satisfaction) on the premature removal of mm-sources and the fact that |
3 |
> no stable version was left in portage. This had the effect of breaking |
4 |
> a number of perfectly working systems and leaving no alternative but to |
5 |
> move to another kernel as the masked versions did not work (at the time) |
6 |
> - a major hassle. |
7 |
|
8 |
I'm probably missing something obvious, but even reading the original |
9 |
bug report leaves me confused as to how a lack of stable mm-sources |
10 |
ebuilds is breaking systems. Once mm-sources is installed anything |
11 |
that needs a kernel tree should build just fine. (I don't think |
12 |
we have anything in the tree that specifically requires mm-sources, |
13 |
do we?) If the problem is that somebody wants to install mm-sources but |
14 |
can't because all ebuilds are arch-masked, then that's what |
15 |
/etc/portage/package.keywords is for. |
16 |
|
17 |
I don't know what the official thinking on this is, but off-the-cuff I |
18 |
would tend to think that _all_ mm-sources ebuilds should really be arch |
19 |
masked, since mm-sources is both bleeding-edge (by definition) and a |
20 |
fast-moving target, so one expects that mm-sources ebuilds aren't likely |
21 |
to be in the tree long enough to really become "stable". Only |
22 |
arch-masking release candidates seems a tad silly. I suppose that one |
23 |
might argue that they should be package masked, but since new kernels |
24 |
aren't built and used automatically, I would prefer to just leave it up |
25 |
to users to decide whether or not to build and use any given kernel. |
26 |
|
27 |
> I for one would like to see a policy for this as I feel that mm-sources |
28 |
> was done at the whim of a dev who was looking at his future, and wasnt |
29 |
> willing to consider the user base, leaving quite a number of us |
30 |
> stranded. His justification seemed to be that mm-sources should be |
31 |
> considered a dev package, so I should not have bothered - bug closed. |
32 |
|
33 |
I agree that Greg's bug report was a tad terse, but I rather doubt that |
34 |
your allegation of his motivation is correct. |
35 |
|
36 |
Now, as to the actual issue at hand, the common unwritten policy is that |
37 |
packages generally have one (or at most a few) stable ebuild(s) and zero |
38 |
or more arch-masked ebuilds. Ideally, every mature package should have |
39 |
a stable ebuild (preferably stable on every arch), but.... That said, |
40 |
it's not a written policy because some packages have different needs, |
41 |
and it's mostly up to the package maintainer to make those decisions. |
42 |
|
43 |
Incidentally, we often have people suggest that ebuilds should never be |
44 |
removed from the tree. Then these sorts of problems would never arise. |
45 |
If you've done a new install recently, though, you already know how long |
46 |
it takes to download the initial tree, and that's with fairly active |
47 |
pruning. That's a problem that we don't have a really good solution |
48 |
just yet, so for the moment we try to keep the tree pruned and we let |
49 |
users who need old versions extract them from viewcvs. |
50 |
|
51 |
Best, |
52 |
g2boojum |
53 |
-- |
54 |
Grant Goodyear |
55 |
Gentoo Developer |
56 |
g2boojum@g.o |
57 |
http://www.gentoo.org/~g2boojum |
58 |
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 |