| 1 |
On Sat, 26 Nov 2016 17:32:02 -0600 |
| 2 |
William Hubbs <williamh@g.o> wrote: |
| 3 |
|
| 4 |
> Listing the architectures seems redundant if they are also in the cc: |
| 5 |
> field. In your example above, why would you need arm in the cc: field |
| 6 |
> for app-foo/bas-2.3.4? |
| 7 |
|
| 8 |
Often, the required work for "lists of keywords/stabilizations" has inconsistency. |
| 9 |
|
| 10 |
e.g: Often you'll have only a few packages that need actioned on one arch |
| 11 |
and you'll need a dozen or so that need actioned on others. |
| 12 |
|
| 13 |
Hence, breaking them down to have keywords on the atom lines allows for a quick |
| 14 |
grep of what's affected. |
| 15 |
|
| 16 |
For example, https://bugs.gentoo.org/show_bug.cgi?id=599550#c0 |
| 17 |
|
| 18 |
Where I sorted everything to minimise how tall each list would be. |
| 19 |
|
| 20 |
Only 3 packages needed actioned to satisfy ~arm, ~hppa and ~ppc |
| 21 |
|
| 22 |
7 packages needed action for ~alpha |
| 23 |
|
| 24 |
10 packages needed action for ~ppc64 |
| 25 |
|
| 26 |
and 14 packages needed action for ~ia64 and ~sparc |
| 27 |
|
| 28 |
People who process such lists of course are free to ignore this metadata. |
| 29 |
|
| 30 |
But I'd imagine having a short checklist of "tweak these and it should work" |
| 31 |
to be helpful. |
| 32 |
|
| 33 |
*especially* given the current default behaviour of `ekeyword`, where calling |
| 34 |
|
| 35 |
ekeyword ~foo |
| 36 |
|
| 37 |
Will unintentionally downgrade stable to ~arch, even though the point was to |
| 38 |
change from unkeyworded to ~arch. |
| 39 |
|
| 40 |
Surely though, we could fix that? |
| 41 |
|
| 42 |
ekeyword --as-needed ~foo PKGHERE |
| 43 |
|
| 44 |
Plz? |
Archives