Re: [gentoo-dev] Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])

[Ciaran McCreesh]

On Mon, 24 Dec 2007 10:52:53 +0000
Steve Long <slong@××××××××××××××××××.uk> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 24 Dec 2007 06:03:12 +0000
> > Steve Long <slong@××××××××××××××××××.uk> wrote:
> >> *  Set the EAPI inside the ebuild in a way that makes it easy to
> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is
> >> no backward compatibility issue.
> >
> > It's both a backwards and a forwards compatibility issue.
> >
> Yeah, so forwards into the future where it's impossible to maintain
> this format (er..) there'll be another type of ebuild for your
> purported long-term solution.

Hopefully that'll be EAPI 2, and hopefully we're talking months rather
than years.

> > And eclasses are an entirely separate issue. They need to
> > be dealt with differently, ideally starting with EAPI 2.
> >
> But they come under the scope of this discussion, since this is about
> the long-term future of *every* EAPI. So let's discuss them.

Ok. What technically sound ideas that have been implemented in a real
package manager and tried out on a large, real tree maintained by
multiple developers do you have about improving eclasses with respect
to EAPI handling? I'm curious, because the only solutions we have for
working with the current system are going to suck in the long term (but
equally, they do work with EAPI 0/1, which means they're fine for short
term), and I've yet to hear of a solution that is implementable (both
theoretically and practically), usable from a tree perspective and
scalable across EAPIs.

To start you off, here's a list of ideas that suck:

* Per-EAPI eclasses, or a master eclass that uses sub-eclasses for
whichever EAPI is in use. This is the best general current solution, but
it gets messy very quickly with new EAPIs.

* Eclasses enforcing EAPI restrictions either by global scope or
pkg_setup die. The former's illegal, breaks the metadata cache as it's
done currently, and is way too easy for developers to screw up. The
latter is way too easy for developers to screw up, results in users
seeing the mess and doesn't allow package managers to work around it.

* Variant: eclasses forcibly setting EAPI to OOPS-SOMEONE-SCREWED-UP if
they don't support the eclass used. This one's actually ok from a
package manager perspective, but lousy from a developer testing thing
perspective.

* Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor
across EAPIs removing features, nor EAPIs changing eclasses.

* Some kind of list of supported EAPIs in an eclass. Still has to deal
with EAPI 0 and 1, and doesn't work well across multiple eclasses.

* Banning eclasses from using anything that isn't supported in every
EAPI. Makes new features rather useless, and removing things rather
difficult...

* Crazy hackery involving making 'inherit' look somewhere else in
future EAPIs. At best you'd end up having stub eclasses (again with no
particularly nice way of saying 'oops') to deal with EAPIs 0 and 1.

* Introduce some new global scope eclass-like function that, combined
with supported EAPI sets, does have a proper way of signalling 'not
supported' (and throw in per cat/pkg eclasses because you can).
Unfortunately, you can't do this without breaking current EAPI 0 / 1
package managers, unless you also switch file extensions or some
equivalent op.

All but the last of these are nowhere near good enough. The last one
may or may not be OK as a starting point, but everyone I've spoken to
who's worked with a real multiple EAPI repo agrees that it's a long way
off being a good enough idea that it's worth considering having serious
discussion about it.

So go ahead and start discussing eclasses, if you want. But first I
suggest getting lots and lots of experience and making damned sure you
understand how everything works...

-- 
Ciaran McCreesh
-- 
gentoo-dev@g.o mailing list