On Tue, 13 Nov 2007 12:22:03 -0800 Chris Gianelloni <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
