On Tue, 13 Nov 2007 12:22:03 -0800
Chris Gianelloni <wolf31o2@g.o> wrote:
> 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.

That was only the case because previously, using new features that
Portage didn't support would cause horrible breakage. Now, instead, the
ebuilds show up as being masked.

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

They just need to upgrade their package manager first. Easy.

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

Doing an entire eclass for one specific EAPI generally isn't a good idea
since it's fairly likely that EAPI bumps will be a fairly common thing.

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

A solution with EAPI-agnostic code in foo-common.eclass and
EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more
readable and maintainable in most cases.

-- 
Ciaran McCreesh