Re: [gentoo-dev] rfc: revisiting our stabilization policy

["Manuel Rüger" <mrueg@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/17/2014 06:08 PM, grozin@gentoo.org wrote:
> On Fri, 17 Jan 2014, Tom Wijsman wrote:
>> On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller
>> <ulm@gentoo.org> wrote:
>>>>>>>> On Fri, 17 Jan 2014, grozin  wrote:
>>>> Maybe, a good solution is to introduce a special arch,
>>>> "noarch", for such packages (similar to what's done in the
>>>> rpm world). Then, if a package is ~noarch, it is
>>>> automatically considered ~arch for all arches. Similar for
>>>> stable. The maintainer should be able to keyword ~noarch and
>>>> to stabilize noarch. Comments?
>>> 
>>> How would you handle dependencies in such a scenario? All
>>> dependencies must be keyworded or stable on all architectures,
>>> before the package can be keyworded or stabilised on noarch?
>> 
>> Maybe we can let the package managers only perceive it as
>> keyworded or stable if all of its dependencies are keyworded or
>> stable on the architecture that the user runs. Then we can have
>> repoman just ignore checking dependencies' keywords when we
>> keyword or stabilize them.
> Very reasonable.
> 
> Andrey
> 


I think the idea itself is good, but we should not add this to
KEYWORDS directly, as it might cause some problems with older package
managers(?).

A new variable can be introduced, which will overwrite testing
keywords to stable keywords, if the var is set to "stable" and keeps
everything in KEYWORDS marked as testing otherwise.

If this var exists in an ebuild and there is a new stabilization bug,
the arch team can decide if they want to mark it stable for all
architectures (via setting the var to stable) or only for the
architecture they tested it for (if some dependencies are missing on
other architectures).
This practice ensures that at least one arch team member of any arch
tested it.

The use of the to-be-added variable could also be extended for
vulnerability fixing.
It's more important to users to deal with less vulnerabilities for a
long time than a working stable dependency tree. Because the latter
got easier with the autounmask feature in portage.

If the var is set by the maintainer to "security-fix-$bugid" and the
users add an option to their profile, it automatically sets the ebuild
to stable and prompts an info with the bugid.
Users who do not want to wait for stabilization or GLSA have a better
possibility to secure their system earlier.
The advantage in general is that quickly added fixes get a wider
testing. So stable users will also profit.


Cheers

Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJ8BAEBCgBmBQJS2cwvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1
OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcpuwP/27np/ekt9AWHJz/OC7BpDz8
gxrE0iuocczV6m5/CejSY8GEdd26xQRdyloZ/7f74W1I5jRB/WPbHUKa0dnglZba
AG/WRJRYOao6537t5p9n6knH3Bj0wIcZl90Jox80HOXsvk/eBwZaliE+jcA+6Mat
Dcl0FVgl/b1WJZaa0aEt5st8nnW5TJ5ZTuWBG6e6shH94qAFcr8VWLOTtY1xqvHf
U1GHlynM4h+nX7BnDlhPxPf2l9XPBZNQFOAvWfvE341uZcSUpkQYfYzpo2TKdYop
oPL6hfMsHq5uggB0OvVaf4CiuCKhV3re7GVexKJE9Moigrb0v/nWCy5ApvR0Ww/N
7wozyGcWUKc/oHW3CHGAYr4wbFjjI9LjB5IVEjmEAGmJ5bq7/RViM+5slj/s9kBe
Vioti6i2vYVs4awm/HrMvremVUJ03Deh8uwVnOaggyrggRnwbxEsRxdsMCmYNkKN
2xAVvnSi2YEMSwBWvClRJwFvvrZzzsWd+t2Y/e/VqAFNvZn0H0lqZAP1+z540nzU
I7f2ym88jedwRJq41q6TgI9XaHlTFXLMcb9Hu19Xv/faUu5jHxg+ZvQtIwC/2YRy
6La1PGO9uk0wHOgixHe/bPXmZ2ArTHB6pAzgiLMpQxuahJhbGXiTmjM8qBc8IKD2
t0VP0WhLWZahQtQ21vrW
=UumH
-----END PGP SIGNATURE-----