| 1 |
On Tue, 28 Mar 2017 00:00:30 +0100 |
| 2 |
"M. J. Everitt" <m.j.everitt@×××.org> wrote: |
| 3 |
|
| 4 |
> 'unstable' should surely be applied to masked packages, no? Everything |
| 5 |
> not-stable and not-unstable becomes therefore 'testing' ... |
| 6 |
|
| 7 |
Nah, he's trying to make the phrase "stable arch" mean something |
| 8 |
in a way tools can understand. |
| 9 |
|
| 10 |
Because we currently have stable arches as a concept, but as far |
| 11 |
as portage is concerned, we only have stable *profiles*, but we can |
| 12 |
only identify specific profiles with arches ... which means ... |
| 13 |
|
| 14 |
We can't have a value of ~arch that we can test without also |
| 15 |
implying the experimental profiles of that arch that don't matter. |
| 16 |
|
| 17 |
Hence, |
| 18 |
|
| 19 |
stable - what it currently means |
| 20 |
|
| 21 |
testing - for architectures where there will be no promises |
| 22 |
beyond "Somebody tested it once" and a 'stable' KEYWORD |
| 23 |
value does not mean anything more than a '~' KEYWORD value. |
| 24 |
|
| 25 |
Where the objective is to make sure at least for an architecture |
| 26 |
developers should spend effort to keep that keywording in place, |
| 27 |
but not ever bother with stabilizing. |
| 28 |
|
| 29 |
unstable - This architecture is so undermaintained that no encouragement |
| 30 |
is made of developers to keep keywords consistent, and they can be freely |
| 31 |
ignored. |
| 32 |
|
| 33 |
This is why I preferred alternative wording that was descriptive of what |
| 34 |
its doing instead of so obscure and generic and over-conflated. |
| 35 |
|
| 36 |
keyword-consistency=literal-match # 'stable' |
| 37 |
|
| 38 |
keyword-consistency=mixed # 'testing' |
| 39 |
|
| 40 |
keyword-consistency=none # 'unstable' |
| 41 |
|
| 42 |
Or something along those lines. |
Archives