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.
