| 1 |
On Sun, 11 Nov 2007 21:50:05 +0100 |
| 2 |
Fabian Groffen <grobian@g.o> wrote: |
| 3 |
> In this setting, one could say that eclasses should remain EAPI=0, |
| 4 |
> such that all ebuilds will be able to work with them. |
| 5 |
|
| 6 |
Mm. Slight problem with wording here, which is causing confusion. |
| 7 |
|
| 8 |
Eclasses don't have an EAPI. Nor, strictly speaking, do ebuilds. An |
| 9 |
EAPI is something that belongs to a cat/package-version::repo as a |
| 10 |
whole, in the same way that DESCRIPTION etc does. Eclasses and ebuilds |
| 11 |
on their own can merely support one or more different EAPIs. |
| 12 |
|
| 13 |
> However, if an EAPI will require some change that makes it backwards |
| 14 |
> incompatible then this won't work any more. What you get is that e.g. |
| 15 |
> for an eclass to work properly it needs to know about variable X, |
| 16 |
> which of course on previous EAPIs does not exist, and hence can |
| 17 |
> result in undesired behaviour. |
| 18 |
|
| 19 |
Doesn't work going the other way too. Forcing eclasses to stick with |
| 20 |
EAPI 1 means no slot deps, and the biggest use case for slot deps is |
| 21 |
the KDE / Qt eclass mess. |
| 22 |
|
| 23 |
> While Ciaran's suggestion would allow some things to work there, it |
| 24 |
> still does not deal with the issue that eclasses should actually be |
| 25 |
> marked with an EAPI level too. |
| 26 |
|
| 27 |
Doesn't make sense. You can't have different EAPIs for different parts |
| 28 |
of the same cat/pkg-version::repo. It wouldn't make sense for metadata |
| 29 |
because you'd be merging different EAPIs into a single variable, and it |
| 30 |
wouldn't make sense for functions because you can call between ebuilds |
| 31 |
and eclasses and back again. |
| 32 |
|
| 33 |
> (Ideally they also would be part of the digests of an ebuild, but |
| 34 |
> that aside.) |
| 35 |
|
| 36 |
Would force a resign and redigest of every ebuild using an eclass every |
| 37 |
time that eclass changed. Not doable. |
| 38 |
|
| 39 |
> A slight alternative to Ciaran's idea here would be to make EAPI1, |
| 40 |
> EAPI2 etc. subdirs in the eclass directory where sort of eclass |
| 41 |
> overloading can be done. This would only solve eclasses not to have |
| 42 |
> an EAPI= in it, so they don't overwrite the ebuild's value. |
| 43 |
|
| 44 |
That would require an EAPI bump. And if we're making inherit look in |
| 45 |
lots of places, there're several other proposals in that area that |
| 46 |
should be considered at the same time. |
| 47 |
|
| 48 |
-- |
| 49 |
Ciaran McCreesh |
Archives