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

[Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]

On Tue, 13 Nov 2007 16:17:59 -0800
Chris Gianelloni <wolf31o2@gentoo.org> wrote:
> 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.

...so you just ensure that the handbook tells the user to upgrade the
package manager as quickly as possible.

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

Uh huh, so if someone does something immensely stupid things go wrong.
How is this anything new?

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

Eh? We already expect users to do lots on their own. Are you suggesting
that we should take over maintaining everyone's system for them?

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

Read it (and my explanation of it earlier in the thread) until you
understand it. There is nothing consistent in what I'm saying.

EAPI specific eclasses are a bad idea. Providing EAPI-agnostic eclasses
by way of multiple EAPI-specific shell eclasses is a good idea.

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

No no, it is as simple as I make it sound (which isn't simple simple,
but it isn't any more complicated than things people have to do
already).

If people stick to a) the way I described of handling non-trivial
eclasses that need to care about EAPIs, b) not using new EAPIs on
things that are hard deps of the package manager that aren't already in
the stageball and c) not nuking the last EAPI 0 versions of a package,
there isn't a problem.

In particular, there is absolutely no need to wait for updated stages
before using EAPI 1 for non-system packages. There isn't even a need to
avoid using EAPI 1 of things that are deps of a package manager, so
long as there remain EAPI 0 versions that are sufficient to satisfy the
dependencies.

For example, you could quite happily mark, say, doxygen 1.5 as EAPI 1,
without breaking the upgrade or install path for Paludis. Paludis 0.24
or older Portage would simply select doxygen 1.4 rather than 1.5, and
then once you'd upgraded to Paludis 0.26 the doxygen 1.5 update would
become available. The problem only occurs if either EAPI 0 versions are
nuked or if particular versions are required.

> All it takes is one person adding an EAPI into an eclass
> somewhere to completely screw over a *huge* number of our users.

All it takes is one person making any silly change to an eclass to
screw over a huge number of users.

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

EAPI *can't* be set in an eclass correctly anyway because EAPI is
allowed to (and likely will in the future) change the behaviour of
inherit.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]