1 |
> |
2 |
> > Another option is to create a separate category for these, something |
3 |
> > like pre-vanilla-sources. This has the benefit that people who want |
4 |
> > vanilla will get only vanilla, and not a prerelease -- regardless of |
5 |
> > which profile they are using. |
6 |
> |
7 |
> I don't like this idea (even though I'm in the minority here :). First |
8 |
> of all, when the _pre's are finished and the stable kernel is |
9 |
> released, people which are using pre-vanilla-sources will be stuck at |
10 |
> the latest _pre (or_testing). |
11 |
|
12 |
I think the idea here was to also include _rc kernels in this category. |
13 |
Since an _rc generally becomes the stable when it is deemed worthy, |
14 |
people shouldn't really be behind here (except by version number, not |
15 |
content). |
16 |
|
17 |
In the case where there are a couple last minute changes from the final |
18 |
_rc to the next stable release, then yes, this could be a problem :\ |
19 |
(although I don't know if this actually happens or not). |
20 |
|
21 |
> |
22 |
> And when they emerge the vanilla-sources, they'll miss the next _pre |
23 |
> cycle. |
24 |
> |
25 |
> Personally, I would go for package.mask |
26 |
> |
27 |
|
28 |
package.mask is what I was really trying to avoid. It's always a pain |
29 |
to have to unmask a package if you want to use it. These kernels are |
30 |
usually quite stable, and I don't think they deserve to be hard masked. |
31 |
|
32 |
I'm still open to suggestions on this though... |
33 |
|
34 |
-- |
35 |
gentoo-dev@g.o mailing list |