1 |
On Sun, 2014-01-19 at 10:46 +0100, Ulrich Mueller wrote: |
2 |
> Now what problem are we trying to solve? As I see it, it is mainly |
3 |
> one of manpower, namely that some arch teams cannot keep up with |
4 |
> stable requests, and I doubt that any technical solution will help |
5 |
> to solve this. Introducing a "noarch" keyword or allowing "*" will |
6 |
> potentially cause problems with dependency resolution. |
7 |
> |
8 |
> Instead, we should come up with a clear set of rules under what |
9 |
> circumstances package maintainers are allowed to stabilise ebuilds |
10 |
> themselves on all architectures. |
11 |
> |
12 |
|
13 |
When they have machines that cover all architectures - assuming there is |
14 |
some sort of machine code at all. Otherwise, why even bother having |
15 |
stable keywords? Everyone keeps going on about how they will |
16 |
potentially have issues because something old is stable - I've thrown |
17 |
out that maybe we should (after a certain amount of time - when cleaning |
18 |
maybe?) remove all keywords except the only stable one, and then leaving |
19 |
it up to the slow arches. |
20 |
|
21 |
I know what the dev manual says, but I'd much rather have an old ebuild |
22 |
that's KEYWORDS="-* arm" than have that ebuild removed because a new one |
23 |
is KEYWORDS="arm" that doesn't work at all. Everyone else keeps talking |
24 |
in the theoretical, and I'm talking an actual issue. This affects me |
25 |
and my workflow and ask ryao about how he wanted to emerge git-9999 to |
26 |
look into fixing it... |
27 |
|
28 |
|
29 |
-- steev |