-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/17/2014 06:08 PM, gro...@gentoo.org wrote: > On Fri, 17 Jan 2014, Tom Wijsman wrote: >> On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller >> <u...@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-----
