[gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms

[Steve Long <slong@rathaus.eclipse.co.uk>]

Jeremy Olexa wrote:

> Fabian Groffen wrote:
> <snip>
>> Most notably, in Prefix all keywords are full GLEP53 style, which
>> results in e.g. amd64-linux.  We did this on purpose, because in Prefix
>> we don't necessarily are on Gentoo Linux.  We also chose to expand fbsd,
>> nbsd and obsd to their long variants, mainly because the short variants
>> might clash in the future, for e.g. OpenBSD, OliveBSD or PicoBSD,
>> polyBSD or DragonflyBSD, DesktopBSD.  (At some point we were a bit
>> over-enthausiastic.)
>> 
>> I would like to hear some opinions on the keywords in general, as well
>> as the particular problem of having Gentoo Linux, and a Linux supported
>> by Gentoo Prefix.

Would it not be simpler just to say the keyword can be from 1 to 4
hypen-separated parts, 1 as-is (in both GLEPS) 2 as GLEP 53, 3 with libc
change, and 4 with non-default userland as per GLEP22 (perhaps change the
order to be more intuitive, if you think it would be better)?

>> Right now there is just the difference of "-linux" 
>> appended, however this is not the clearest distinction between the two.
>> Perhaps using KEYWORDS for Prefix keywords is not the best thing to do,
>> and should we use something like PREFIX_KEYWORDS?
> 
> Ignoring the bit about how to name the keywords.. ;)
> 
> I am undecided about Prefix keywords in the normal KEYWORDS variable. In
> particular, we are overloading the -linux keyword to mean that it will
> run on any linux that Gentoo Prefix supports. This includes, Gentoo,
> RHEL, SLES, FreeMint, $OTHER.
> 
> Is there any problem with "overloading" the keywords like that? If not,
> then it shouldn't be a problem to keep prefix keywords in the KEYWORDS
> field. OTOH, I don't think we should add another variable to ebuilds.
> 
> Thoughts?
> 
Wrt to the variable thing, I agree the specification of prefix is orthogonal
to the spec of an EAPI. Orthogonality [at least in sw terms] doesn't just
mean "nothing to do with it whatsoever," or it wouldn't apply to the
software in question.

Unless someone can say what using PROPERTIES=prefix would break, I'd go with
that. It's a /classic/ usage of that variable, as it's simply a boolean;
PROPERTIES is well-defined and I'm hoping all the manglers support it. It'd
be great to see the prefix branch finally merged so we all get to play with
it.