Gentoo Archives: gentoo-dev

From: "Manuel RĂ¼ger" <mrueg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Sat, 18 Jan 2014 00:35:21
Message-Id: 52D9CC2F.5000503@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by grozin@gentoo.org
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA512
3
4 On 01/17/2014 06:08 PM, grozin@g.o wrote:
5 > On Fri, 17 Jan 2014, Tom Wijsman wrote:
6 >> On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller
7 >> <ulm@g.o> wrote:
8 >>>>>>>> On Fri, 17 Jan 2014, grozin wrote:
9 >>>> Maybe, a good solution is to introduce a special arch,
10 >>>> "noarch", for such packages (similar to what's done in the
11 >>>> rpm world). Then, if a package is ~noarch, it is
12 >>>> automatically considered ~arch for all arches. Similar for
13 >>>> stable. The maintainer should be able to keyword ~noarch and
14 >>>> to stabilize noarch. Comments?
15 >>>
16 >>> How would you handle dependencies in such a scenario? All
17 >>> dependencies must be keyworded or stable on all architectures,
18 >>> before the package can be keyworded or stabilised on noarch?
19 >>
20 >> Maybe we can let the package managers only perceive it as
21 >> keyworded or stable if all of its dependencies are keyworded or
22 >> stable on the architecture that the user runs. Then we can have
23 >> repoman just ignore checking dependencies' keywords when we
24 >> keyword or stabilize them.
25 > Very reasonable.
26 >
27 > Andrey
28 >
29
30
31 I think the idea itself is good, but we should not add this to
32 KEYWORDS directly, as it might cause some problems with older package
33 managers(?).
34
35 A new variable can be introduced, which will overwrite testing
36 keywords to stable keywords, if the var is set to "stable" and keeps
37 everything in KEYWORDS marked as testing otherwise.
38
39 If this var exists in an ebuild and there is a new stabilization bug,
40 the arch team can decide if they want to mark it stable for all
41 architectures (via setting the var to stable) or only for the
42 architecture they tested it for (if some dependencies are missing on
43 other architectures).
44 This practice ensures that at least one arch team member of any arch
45 tested it.
46
47 The use of the to-be-added variable could also be extended for
48 vulnerability fixing.
49 It's more important to users to deal with less vulnerabilities for a
50 long time than a working stable dependency tree. Because the latter
51 got easier with the autounmask feature in portage.
52
53 If the var is set by the maintainer to "security-fix-$bugid" and the
54 users add an option to their profile, it automatically sets the ebuild
55 to stable and prompts an info with the bugid.
56 Users who do not want to wait for stabilization or GLSA have a better
57 possibility to secure their system earlier.
58 The advantage in general is that quickly added fixes get a wider
59 testing. So stable users will also profit.
60
61
62 Cheers
63
64 Manuel
65 -----BEGIN PGP SIGNATURE-----
66 Version: GnuPG v2.0.22 (GNU/Linux)
67 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
68
69 iQJ8BAEBCgBmBQJS2cwvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
70 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
71 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcpuwP/27np/ekt9AWHJz/OC7BpDz8
72 gxrE0iuocczV6m5/CejSY8GEdd26xQRdyloZ/7f74W1I5jRB/WPbHUKa0dnglZba
73 AG/WRJRYOao6537t5p9n6knH3Bj0wIcZl90Jox80HOXsvk/eBwZaliE+jcA+6Mat
74 Dcl0FVgl/b1WJZaa0aEt5st8nnW5TJ5ZTuWBG6e6shH94qAFcr8VWLOTtY1xqvHf
75 U1GHlynM4h+nX7BnDlhPxPf2l9XPBZNQFOAvWfvE341uZcSUpkQYfYzpo2TKdYop
76 oPL6hfMsHq5uggB0OvVaf4CiuCKhV3re7GVexKJE9Moigrb0v/nWCy5ApvR0Ww/N
77 7wozyGcWUKc/oHW3CHGAYr4wbFjjI9LjB5IVEjmEAGmJ5bq7/RViM+5slj/s9kBe
78 Vioti6i2vYVs4awm/HrMvremVUJ03Deh8uwVnOaggyrggRnwbxEsRxdsMCmYNkKN
79 2xAVvnSi2YEMSwBWvClRJwFvvrZzzsWd+t2Y/e/VqAFNvZn0H0lqZAP1+z540nzU
80 I7f2ym88jedwRJq41q6TgI9XaHlTFXLMcb9Hu19Xv/faUu5jHxg+ZvQtIwC/2YRy
81 6La1PGO9uk0wHOgixHe/bPXmZ2ArTHB6pAzgiLMpQxuahJhbGXiTmjM8qBc8IKD2
82 t0VP0WhLWZahQtQ21vrW
83 =UumH
84 -----END PGP SIGNATURE-----