Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Chris Gianelloni]

On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote:
> I plan to make the java eclasses use the EAPI 1

Any chance we can *at least* wait until we have a release out the door
that has a portage version which supports these features *before* we
start trying to use them in the tree?  Our general rule was to not use
features for 1+ years since it was added to a *stable* portage before we
started using them.  Now, this isn't so much of an issue with individual
ebuilds, but you're talking about changing how the Java eclasses work,
essentially blocking *anyone* using an older portage (including everyone
installing from 2007.0 media) from using any package which inherits the
eclass.

Also, we should really think about this sort of thing before we start
using it.  How are we going to support EAPI changes in eclasses?  What
if I have an eclass with EAPI=1 features and I want to add some EAPI=2
features?  I think allowing EAPI=* globally in an eclass should be
prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds,
only.  In other words, you'd need new EAPI=1 eclasses for your EAPI=1
ebuilds.  Either that, or some way to say something like: "execute code
path A for EAPI=0 and execute code path B for EAPI=1" or something
similar.  I would suspect that the "best" current solution is to check
EAPI in the individual functions and perform the right actions based on
those functions, rather than marking an entire eclass.  After all, only
EAPI=* functions need to be "hidden" behind EAPI.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation