1 |
Jeremy Olexa wrote: |
2 |
|
3 |
> Fabian Groffen wrote: |
4 |
> <snip> |
5 |
>> Most notably, in Prefix all keywords are full GLEP53 style, which |
6 |
>> results in e.g. amd64-linux. We did this on purpose, because in Prefix |
7 |
>> we don't necessarily are on Gentoo Linux. We also chose to expand fbsd, |
8 |
>> nbsd and obsd to their long variants, mainly because the short variants |
9 |
>> might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD, |
10 |
>> polyBSD or DragonflyBSD, DesktopBSD. (At some point we were a bit |
11 |
>> over-enthausiastic.) |
12 |
>> |
13 |
>> I would like to hear some opinions on the keywords in general, as well |
14 |
>> as the particular problem of having Gentoo Linux, and a Linux supported |
15 |
>> by Gentoo Prefix. |
16 |
|
17 |
Would it not be simpler just to say the keyword can be from 1 to 4 |
18 |
hypen-separated parts, 1 as-is (in both GLEPS) 2 as GLEP 53, 3 with libc |
19 |
change, and 4 with non-default userland as per GLEP22 (perhaps change the |
20 |
order to be more intuitive, if you think it would be better)? |
21 |
|
22 |
>> Right now there is just the difference of "-linux" |
23 |
>> appended, however this is not the clearest distinction between the two. |
24 |
>> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do, |
25 |
>> and should we use something like PREFIX_KEYWORDS? |
26 |
> |
27 |
> Ignoring the bit about how to name the keywords.. ;) |
28 |
> |
29 |
> I am undecided about Prefix keywords in the normal KEYWORDS variable. In |
30 |
> particular, we are overloading the -linux keyword to mean that it will |
31 |
> run on any linux that Gentoo Prefix supports. This includes, Gentoo, |
32 |
> RHEL, SLES, FreeMint, $OTHER. |
33 |
> |
34 |
> Is there any problem with "overloading" the keywords like that? If not, |
35 |
> then it shouldn't be a problem to keep prefix keywords in the KEYWORDS |
36 |
> field. OTOH, I don't think we should add another variable to ebuilds. |
37 |
> |
38 |
> Thoughts? |
39 |
> |
40 |
Wrt to the variable thing, I agree the specification of prefix is orthogonal |
41 |
to the spec of an EAPI. Orthogonality [at least in sw terms] doesn't just |
42 |
mean "nothing to do with it whatsoever," or it wouldn't apply to the |
43 |
software in question. |
44 |
|
45 |
Unless someone can say what using PROPERTIES=prefix would break, I'd go with |
46 |
that. It's a /classic/ usage of that variable, as it's simply a boolean; |
47 |
PROPERTIES is well-defined and I'm hoping all the manglers support it. It'd |
48 |
be great to see the prefix branch finally merged so we all get to play with |
49 |
it. |