| 1 |
Hi Ciaran, |
| 2 |
|
| 3 |
Ciaran McCreesh wrote: [Tue Jun 22 2004, 01:52:36PM EDT] |
| 4 |
> I think it won't work, because there are already stacks of packages |
| 5 |
> in the tree where the keywording order is arbitrary. |
| 6 |
|
| 7 |
I agree, there are many with an arbitrary order. Hopefully--and |
| 8 |
probably--not the packages that start these kinds of arguments. I |
| 9 |
suspect most of those presently start with the package maintainer's |
| 10 |
arch, purely because they have been actively maintained instead of |
| 11 |
willy-nilly. |
| 12 |
|
| 13 |
Here are changes to ekeyword that I would consider *necessary* to make |
| 14 |
this work without it being a burden: |
| 15 |
|
| 16 |
1. Warn when jumping ahead of maintainer's arch. This should happen |
| 17 |
at repoman time as well. |
| 18 |
|
| 19 |
2. Automatically recognize a maintainer: |
| 20 |
|
| 21 |
(a) check metadata.xml for a match against either |
| 22 |
ECHANGELOG_USER or current username. |
| 23 |
|
| 24 |
(b) read herd from metadata.xml and cross-reference against |
| 25 |
herds.xml to determine if current user is part of the team |
| 26 |
maintaining this herd. |
| 27 |
|
| 28 |
If maintainer is recognized, then move stable keyword to front of |
| 29 |
KEYWORDS. Of course, ekeyword should inform when it does this! |
| 30 |
|
| 31 |
3. Automatically recognize when non-maintainer appears to be marking |
| 32 |
first keyword in list stable, and warn about it. |
| 33 |
|
| 34 |
> Why not put a <maintainernotes> in metadata.xml instead? Much cleaner, |
| 35 |
> provides much more information, |
| 36 |
|
| 37 |
The problem I have with that approach is the weight of it. All the |
| 38 |
metadata.xml files would need that addition. It's similar to doing a |
| 39 |
"stable" keyword (my earlier suggestion, I admit) or using a special |
| 40 |
marker on a keyword. It would take a lot of time to implement |
| 41 |
throughout the tree, whereas the solution I'm suggesting would be more |
| 42 |
immediately available (though I agree with you that there are plenty |
| 43 |
of ebuilds in the tree with an arbitrary order). |
| 44 |
|
| 45 |
> doesn't imply meaning in an existing |
| 46 |
> field which does not currently provide any information. |
| 47 |
|
| 48 |
Actually, that isn't true. It was established previously that the |
| 49 |
order of keywords would indicate the order in which they were added to |
| 50 |
an ebuild. This was agreed upon about a year ago (I recall that |
| 51 |
drobbins took part in the discussion). Ekeyword adheres to that |
| 52 |
established precedent, which means that presently there should be a |
| 53 |
lot of ebuilds that contain the maintainer's arch first in the list. |
| 54 |
|
| 55 |
Regards, |
| 56 |
Aron |
| 57 |
|
| 58 |
-- |
| 59 |
Aron Griffis |
| 60 |
Gentoo Linux Developer |
Archives