Re: [gentoo-dev] Re: Add a KEYWORD representing any arch
On Sun, 19 Jan 2014 10:46:28 +0100 Ulrich Mueller u...@gentoo.org wrote: Instead, we should come up with a clear set of rules under what circumstances package maintainers are allowed to stabilise ebuilds themselves on all architectures. The cases where stabilisation is important (for security, progress) are usually those where this arbitrary type of stabilisation is not an option, unless we drop all pretence of upholding the dictionary meaning of stabilisation. What we need is architecture teams that clearly do the work (as a team), or we drop their stable status. Recent advances in stabilisation practices certainly haven't helped establish a reliable picture of some teams. If a team cannot keep up stabilising thousands of packages, then it should focus in the short term on dropping keywords for extra packages, and then in the long term focus on getting a reliable base system up to date (i.e. drop all the fun keywording and focus on what that platform really must have to get a system running). If all that doesn't pan out, then we should set the QA hounds on them. :) jer
Re: [gentoo-dev] Re: Add a KEYWORD representing any arch
On Sun, 2014-01-19 at 10:46 +0100, Ulrich Mueller wrote: Now what problem are we trying to solve? As I see it, it is mainly one of manpower, namely that some arch teams cannot keep up with stable requests, and I doubt that any technical solution will help to solve this. Introducing a noarch keyword or allowing * will potentially cause problems with dependency resolution. Instead, we should come up with a clear set of rules under what circumstances package maintainers are allowed to stabilise ebuilds themselves on all architectures. When they have machines that cover all architectures - assuming there is some sort of machine code at all. Otherwise, why even bother having stable keywords? Everyone keeps going on about how they will potentially have issues because something old is stable - I've thrown out that maybe we should (after a certain amount of time - when cleaning maybe?) remove all keywords except the only stable one, and then leaving it up to the slow arches. I know what the dev manual says, but I'd much rather have an old ebuild that's KEYWORDS=-* arm than have that ebuild removed because a new one is KEYWORDS=arm that doesn't work at all. Everyone else keeps talking in the theoretical, and I'm talking an actual issue. This affects me and my workflow and ask ryao about how he wanted to emerge git- to look into fixing it... -- steev
[gentoo-dev] Re: Add a KEYWORD representing any arch
On Sun, 19 Jan 2014, Pacho Ramos wrote: El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió: you mean * ? this already works today (at least with portage): KEYWORDS=~* KEYWORDS=* Currently not allowed by policy: http://devmanual.gentoo.org/keywording/index.html I had no idea that existed :O, I guess something related with specification is missing? :/ Now what problem are we trying to solve? As I see it, it is mainly one of manpower, namely that some arch teams cannot keep up with stable requests, and I doubt that any technical solution will help to solve this. Introducing a noarch keyword or allowing * will potentially cause problems with dependency resolution. Instead, we should come up with a clear set of rules under what circumstances package maintainers are allowed to stabilise ebuilds themselves on all architectures. Ulrich pgpiU02gcnyG5.pgp Description: PGP signature
Re: [gentoo-dev] Re: Add a KEYWORD representing any arch
El dom, 19-01-2014 a las 10:46 +0100, Ulrich Mueller escribió: On Sun, 19 Jan 2014, Pacho Ramos wrote: El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió: you mean * ? this already works today (at least with portage): KEYWORDS=~* KEYWORDS=* Currently not allowed by policy: http://devmanual.gentoo.org/keywording/index.html I had no idea that existed :O, I guess something related with specification is missing? :/ Now what problem are we trying to solve? As I see it, it is mainly one of manpower, namely that some arch teams cannot keep up with stable requests, and I doubt that any technical solution will help to solve this. Introducing a noarch keyword or allowing * will potentially cause problems with dependency resolution. Instead, we should come up with a clear set of rules under what circumstances package maintainers are allowed to stabilise ebuilds themselves on all architectures. Ulrich Yeah, the problem is manpower and, then, we are thinking in cases like wallpapers, changes in the installation of some files (that are not arch specific)... But, how to indicate a concrete package can be handled in this special noarch way? It's easy for some cases like I posted, but there are others that are more difficult to handle (perl modules for example?) If we could agree on the kind of packages we could handle in this way (stabilizing for all arches) would be nice
