1 |
Hi all, |
2 |
|
3 |
The Prefix team has a separate Portage branch which implements the |
4 |
"prefix" extensions. In short, this encompasses the addition of the |
5 |
variables EPREFIX, ED and EROOT, and the function eprefixify to the |
6 |
ebuild/eclass environment, which may be used to make an ebuild work for |
7 |
a given prefix offset. |
8 |
|
9 |
I would like to get some input on how best to deal with these additions |
10 |
in the light of EAPI and the main (gentoo-x86) tree and Portage. Since |
11 |
the Prefix extensions can currently be applied on top of any existing |
12 |
EAPI, they are not requiring any special EAPI value as baseline. |
13 |
|
14 |
Currently in Prefix we implemented EAPI as being a set of tokens that |
15 |
are orthogonal to each other. In other words, while 0, 1 and 2 are |
16 |
mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result is |
17 |
something like EAPI="prefix 1". Of course with this approach the recent |
18 |
introduction of EAPI=2, resulted in a problem with eclasses that do a |
19 |
blind check on the EAPI variable to be e.g. 2. |
20 |
An alternative is to create multiple new EAPIs, such as prefix-1 or |
21 |
1-prefix, containing the Prefix extensions on top of EAPI=1. Same |
22 |
problem when checks on EAPI are done of course, but EAPI then always |
23 |
consists of a single value. |
24 |
Something that was raised in previous discussions was that maybe the |
25 |
Prefix extensions don't need an EAPI in itself, but that an ebuild has |
26 |
to be marked as Prefix-ready through e.g. the recently proposed |
27 |
PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be |
28 |
added variable. |
29 |
|
30 |
Please discuss. |
31 |
|
32 |
|
33 |
-- |
34 |
Fabian Groffen |
35 |
Gentoo on a different level |