1 |
On Thu, 9 Oct 2008 19:46:55 +0200 |
2 |
Fabian Groffen <grobian@g.o> wrote: |
3 |
> Currently in Prefix we implemented EAPI as being a set of tokens that |
4 |
> are orthogonal to each other. In other words, while 0, 1 and 2 are |
5 |
> mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result |
6 |
> is something like EAPI="prefix 1". Of course with this approach the |
7 |
> recent introduction of EAPI=2, resulted in a problem with eclasses |
8 |
> that do a blind check on the EAPI variable to be e.g. 2. |
9 |
|
10 |
EAPI's defined as being a single value because mixing between EAPIs is |
11 |
in general impossible. For example, I'm guessing prefix might need to |
12 |
do something to econf / the default src_compile/configure functions at |
13 |
some point, so it's not really truly independent. |
14 |
|
15 |
> An alternative is to create multiple new EAPIs, such as prefix-1 or |
16 |
> 1-prefix, containing the Prefix extensions on top of EAPI=1. Same |
17 |
> problem when checks on EAPI are done of course, but EAPI then always |
18 |
> consists of a single value. |
19 |
|
20 |
That's the sensible way of doing it... |
21 |
|
22 |
The way things are with EAPIs... The only way you'll get things |
23 |
supported in main tree eclasses is if you get the Council to approve a |
24 |
formal specification of what you want. Unfortunately, they seem |
25 |
reluctant to do that even if you're an official Gentoo project (see |
26 |
kdebuild-1). |
27 |
|
28 |
Is there anything stopping you from formalising your specification of |
29 |
what you need? (The PMS team can probably help with the 'writing formal' |
30 |
bit if necessary, given an informal description.) Could it be done in |
31 |
such a way that non-prefix package managers can do minimal support to |
32 |
get the current /usr behaviour, whilst optionally implementing |
33 |
everything else? If this is the case, the best route's probably to get |
34 |
the whole thing into the next EAPI, start using that EAPI for all your |
35 |
overlay packages and persuade people to include the necessary prefixy |
36 |
things in main-tree eclasses (which they should, once said EAPI is |
37 |
Council approved). |
38 |
|
39 |
> Something that was raised in previous discussions was that maybe the |
40 |
> Prefix extensions don't need an EAPI in itself, but that an ebuild has |
41 |
> to be marked as Prefix-ready through e.g. the recently proposed |
42 |
> PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be |
43 |
> added variable. |
44 |
|
45 |
What's the scope of the changes? I think it'd be easiest to discuss |
46 |
this if you posted an informal summary describing the differences in |
47 |
terms of which bits of PMS are affected. |
48 |
|
49 |
-- |
50 |
Ciaran McCreesh |