On Thu, 9 Oct 2008 19:46:55 +0200
Fabian Groffen <grobian@g.o> wrote:
> 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.

EAPI's defined as being a single value because mixing between EAPIs is
in general impossible. For example, I'm guessing prefix might need to
do something to econf / the default src_compile/configure functions at
some point, so it's not really truly independent.

> 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.

That's the sensible way of doing it...

The way things are with EAPIs... The only way you'll get things
supported in main tree eclasses is if you get the Council to approve a
formal specification of what you want. Unfortunately, they seem
reluctant to do that even if you're an official Gentoo project (see
kdebuild-1).

Is there anything stopping you from formalising your specification of
what you need? (The PMS team can probably help with the 'writing formal'
bit if necessary, given an informal description.) Could it be done in
such a way that non-prefix package managers can do minimal support to
get the current /usr behaviour, whilst optionally implementing
everything else? If this is the case, the best route's probably to get
the whole thing into the next EAPI, start using that EAPI for all your
overlay packages and persuade people to include the necessary prefixy
things in main-tree eclasses (which they should, once said EAPI is
Council approved).

> 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.

What's the scope of the changes? I think it'd be easiest to discuss
this if you posted an informal summary describing the differences in
terms of which bits of PMS are affected.

-- 
Ciaran McCreesh