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
signature.asc
Description: This is a digitally signed message part
