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

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

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

On Sun, 11 Nov 2007 21:50:05 +0100
Fabian Groffen <grobian@gentoo.org> wrote:
> In this setting, one could say that eclasses should remain EAPI=0,
> such that all ebuilds will be able to work with them.

Mm. Slight problem with wording here, which is causing confusion.

Eclasses don't have an EAPI. Nor, strictly speaking, do ebuilds. An
EAPI is something that belongs to a cat/package-version::repo as a
whole, in the same way that DESCRIPTION etc does. Eclasses and ebuilds
on their own can merely support one or more different EAPIs.

> However, if an EAPI will require some change that makes it backwards
> incompatible then this won't work any more.  What you get is that e.g.
> for an eclass to work properly it needs to know about variable X,
> which of course on previous EAPIs does not exist, and hence can
> result in undesired behaviour.

Doesn't work going the other way too. Forcing eclasses to stick with
EAPI 1 means no slot deps, and the biggest use case for slot deps is
the KDE / Qt eclass mess.

> While Ciaran's suggestion would allow some things to work there, it
> still does not deal with the issue that eclasses should actually be
> marked with an EAPI level too.

Doesn't make sense. You can't have different EAPIs for different parts
of the same cat/pkg-version::repo. It wouldn't make sense for metadata
because you'd be merging different EAPIs into a single variable, and it
wouldn't make sense for functions because you can call between ebuilds
and eclasses and back again.

>  (Ideally they also would be part of the digests of an ebuild, but
> that aside.)

Would force a resign and redigest of every ebuild using an eclass every
time that eclass changed. Not doable.

> A slight alternative to Ciaran's idea here would be to make EAPI1,
> EAPI2 etc. subdirs in the eclass directory where sort of eclass
> overloading can be done.  This would only solve eclasses not to have
> an EAPI= in it, so they don't overwrite the ebuild's value.

That would require an EAPI bump. And if we're making inherit look in
lots of places, there're several other proposals in that area that
should be considered at the same time.

-- 
Ciaran McCreesh

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