List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, 13 Nov 2007 12:22:03 -0800
Chris Gianelloni <email@example.com> 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,
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
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.