On Sun, 11 Nov 2007 21:50:05 +0100 Fabian Groffen <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
