| 1 |
Carsten Lohrke wrote: [Tue Jun 22 2004, 12:47:35PM EDT] |
| 2 |
> On Tuesday 22 June 2004 18:25, Aron Griffis wrote: |
| 3 |
> > I think it's okay if the maintainer's arch jumps around. To do |
| 4 |
> > otherwise would be an unnecessary restriction. |
| 5 |
> |
| 6 |
> In what sense? |
| 7 |
|
| 8 |
Sorry if I wasn't clear. I meant it would be an unnecessary |
| 9 |
restriction to require that the maintainer's arch stays the same |
| 10 |
between ebuild revisions. It happens all the time that a developer |
| 11 |
changes architectures. For example we seem to have a lot of |
| 12 |
developers that are changing from x86 to amd64 as their next machines. |
| 13 |
|
| 14 |
> I can't see any difference in rearranged keywords to a special |
| 15 |
> prefix or extra keyword. Neither in internal representation nor in |
| 16 |
> terms of implementing this in ekeyword. I dislike order dependent |
| 17 |
> configurations much. It's not that visible, as the other two |
| 18 |
> options. |
| 19 |
|
| 20 |
I agree, there isn't much of a difference. Here are the differences: |
| 21 |
|
| 22 |
extra keyword: refrains from marking the maintainer's arch, but |
| 23 |
clearly marks when an ebuild is considered stable by the |
| 24 |
package maintainer. At this point I'm thinking that *knowing* |
| 25 |
the maintainer's arch is nice information to have, and we get |
| 26 |
it for free with the other possibilities. The "extra keyword" |
| 27 |
method requires a gradual transition throughout the tree. I |
| 28 |
think this is the least desirable solution. |
| 29 |
|
| 30 |
special prefix: marks the maintainer's arch clearly, requires a |
| 31 |
gradual transition throughout the tree. |
| 32 |
|
| 33 |
first keyword: not as visible as special prefix. However doesn't |
| 34 |
require a gradual transition for most packages, since in most |
| 35 |
cases the first keyword is already the maintainer's arch. |
| 36 |
This is true simply because the current keywords order |
| 37 |
indicates the order in which the keywords were added. (This |
| 38 |
was standardized by drobbins sometime last year... I will try |
| 39 |
to dig up the email if you are interested) |
| 40 |
|
| 41 |
IMHO it would be easiest to use the first keyword method, with the |
| 42 |
option of transitioning to a special prefix eventually. It would be |
| 43 |
harder to transition in the other direction, so I would prefer to |
| 44 |
start with the first keyword method. |
| 45 |
|
| 46 |
Note regarding order dependence: I'm not a big fan of order dependence |
| 47 |
myself. I'm pushing for special significance on the first keyword in |
| 48 |
the list purely because (1) we already have it, (2) the order of |
| 49 |
keywords is already significant, (3) it's very non-invasive, (4) we |
| 50 |
can change again later if it doesn't work out. |
| 51 |
|
| 52 |
Regards, |
| 53 |
Aron |
| 54 |
|
| 55 |
-- |
| 56 |
Aron Griffis |
| 57 |
Gentoo Linux Developer |
Archives