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

[Chris Gianelloni]

On Tue, 2007-11-13 at 20:31 +0000, Ciaran McCreesh wrote:
> 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.

...which is just as good as "broken" when it happens to a new user first
installing Gentoo and wondering why he can't even follow the directions
in the Handbook.

What brought me to bring this up was the mention of changing of eclasses
which support a large number of ebuilds, effectively masking a
significant portion of the tree from our users.  Let's say that I added
EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature
in one of the functions.  Guess what?  I've now managed to mask
*portage* for users of older portage versions.  In fact, I've managed to
mask paludis and pkgcore, too.  Yes, this is an extreme example.  Yes,
it is completely possible.  Yes, that user would be completely screwed.

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

Expecting users to do pretty much anything on their own is broken
behavior and should not be relied on for package manager compatibility.

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

Umm... So in the paragraph above, you say an EAPI-specific eclass isn't
a good idea, and here you push it as the proposed solution.  Huh?
Consistency, please...

I guess my real point is that we need to be *really* careful when using
this stuff.  It is *not* as simple as you make it out to sound.  All it
takes is one person adding an EAPI into an eclass somewhere to
completely screw over a *huge* number of our users.  I am just trying to
point this out and hopefully get discussion going on how to utilize
these great new features without potentially causing damage to our
user's machines and our reputation.

I still think that EAPI should not be allowed to be set in an eclass
globally.  All I can see is it causing problems for tons of users who
don't have a clue what is happening to their systems.

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