1 |
On Wed, 15 Jan 2014 23:59:49 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
> There was previous discussion of destable-keywording the kernel. How |
5 |
> has that gone? |
6 |
|
7 |
That was for vanilla-sources only, because that has restricted to only |
8 |
the latest upstream version; as that makes the version change almost |
9 |
weekly, the package can't undergo our stabilization procedure. |
10 |
|
11 |
> I've always thought that having a stable policy exception that the |
12 |
> user actually has to deal with for certain packages, particularly |
13 |
> core packages such as the kernel, would be confusing at best. |
14 |
|
15 |
Yes, if this would ever happen to gentoo-sources; I'd think the |
16 |
handbook would then need to be updated to mention the necessary extra |
17 |
step, but I think it is not bound to happen any time soon. |
18 |
|
19 |
> Still, |
20 |
> given the upstream development pattern, I couldn't think of a |
21 |
> reasonable alternative for the kernel, and agreed with the thread |
22 |
> that it may have to be, for packages like that and perhaps |
23 |
> google-chrome and firefox, where upstream releases are too close to |
24 |
> 30-day and updates are very likely to be security-critical on |
25 |
> packages that are net-exposed. |
26 |
|
27 |
What we do now appears to work fine, critical security bugs cause fast |
28 |
track stabilization if needed; I've backported some security fixes in |
29 |
the past for less critical CVEs in the past, but the main problem here |
30 |
for keeping this up is the lack of manpower on the kernel team. |
31 |
|
32 |
> So it seemed it had to be, for them, and if that has gone well, |
33 |
> perhaps expanding that no-stable policy precedent to things like |
34 |
> editor plugins could work better than I might have imagined. |
35 |
|
36 |
I think it needs to put the accept keywords in a more prominent place |
37 |
if we're going to do this at a wider scale; currently it's in one of |
38 |
those sections that people often don't read due to focusing on |
39 |
continuing with there install instead, eg. they move to some DE guide. |
40 |
|
41 |
> The other question then becomes, since ~arch packages are normally |
42 |
> masked to stable, how are users exposed to them? |
43 |
|
44 |
They aren't unless they accept keywords for them; which can either be |
45 |
done globally using package.accept_keywords, or locally |
46 |
by listing the package atom in /etc/portage/package.accept_keywords |
47 |
|
48 |
> What about a file |
49 |
> somewhere in profiles that lists all these no-stable packages, such |
50 |
> that the PM can (perhaps optionally, I could imagine a setting in |
51 |
> make.conf...) list all ~arch versions of those packages on an |
52 |
> otherwise stable system as if they were stable, tho possibly marked |
53 |
> in some way to indicate that this package isn't a stable-keyword |
54 |
> candidate? |
55 |
|
56 |
If we drop stable versions on a wider scale, we could indeed make the |
57 |
~arch versions more visible where they currently aren't; we don't want |
58 |
to give the impression that we are removing everything. |
59 |
|
60 |
-- |
61 |
With kind regards, |
62 |
|
63 |
Tom Wijsman (TomWij) |
64 |
Gentoo Developer |
65 |
|
66 |
E-mail address : TomWij@g.o |
67 |
GPG Public Key : 6D34E57D |
68 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |