On Tue, Mar 10, 2009 at 4:15 AM, Fabian Groffen <grobian@g.o> wrote:
> Sort of responding to/being inspired by haubi's comment on -dev about
> "inherit eapi 4", I wondered whether we should make a prefix.eclass.
>
> Currently we have eprefixify as function provided by Portage, and hence
> ebuilds that use eprefixify cannot be straight ported to gentoo-x86.
> Most notable are the eselect-* ebuilds that some gentoo-x86 devs like to
> give full Prefix support, but simply can't because eprefixify (which we
> would use) cannot be used in gentoo-x86.
>
> So, should we start an eclass with for now eprefixify in there, and for
> every ebuild where we use it, start inheriting prefix and nuke the
> function from Portage?  Somehow I think this is a good idea.
>
> Since I like haubi's idea about inherit doing the magic for eapis,
> perhaps this can even solve the problem we have with our EAPI mungling
> (all our ebuilds just inherit eapi prefix to "tag" them) and all
> eclasses (it remains a hell of a job to keep it working), as well as
> having prefix ebuilds live happily next to non-prefix ones.  But for
> that we really need Portage to be able to mask based on what's in the
> inherit line, e.g. the resolver needs to take it into account.

I'm not opposed to the idea and to be quite frank, we need a better
solution than EAPI=prefix which a) will not be allowed in gentoo-x86
purely based on name[1], b) breaks on every EAPI bump[2], c) is not a
legal use of EAPI anymore[3]

[1]: PMS says that Gentoo can only use numbers (as strings) for EAPI
names. [citation needed, but I know it is true]
[2]: EAPI=prefix extends every EAPI so its a poor choice to be called
an EAPI. Some additional options include PROPERTIES=prefix - which is
restrictable, and other brainstorming that I forgot atm.
[3]: see [2]. initially, EAPI=prefix was thought to be a good use of
EAPI's but I don't think that is true anymore.

-Jeremy