[gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI

[Fabian Groffen <grobian@gentoo.org>]

Hi all,

The Prefix team has a separate Portage branch which implements the
"prefix" extensions.  In short, this encompasses the addition of the
variables EPREFIX, ED and EROOT, and the function eprefixify to the
ebuild/eclass environment, which may be used to make an ebuild work for
a given prefix offset.

I would like to get some input on how best to deal with these additions
in the light of EAPI and the main (gentoo-x86) tree and Portage.  Since
the Prefix extensions can currently be applied on top of any existing
EAPI, they are not requiring any special EAPI value as baseline.

Currently in Prefix we implemented EAPI as being a set of tokens that
are orthogonal to each other.  In other words, while 0, 1 and 2 are
mutual exclusive, "prefix" can be applied to 0, 1, or 2.  The result is
something like EAPI="prefix 1".  Of course with this approach the recent
introduction of EAPI=2, resulted in a problem with eclasses that do a
blind check on the EAPI variable to be e.g. 2.
An alternative is to create multiple new EAPIs, such as prefix-1 or
1-prefix, containing the Prefix extensions on top of EAPI=1.  Same
problem when checks on EAPI are done of course, but EAPI then always
consists of a single value.
Something that was raised in previous discussions was that maybe the
Prefix extensions don't need an EAPI in itself, but that an ebuild has
to be marked as Prefix-ready through e.g. the recently proposed
PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be
added variable.

Please discuss.


-- 
Fabian Groffen
Gentoo on a different level