Robert Bridge wrote: > Patrick Lauer wrote: >> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: >>> On Thu, 14 May 2009 20:06:51 +0200 >>> >>> Patrick Lauer <patr...@gentoo.org> wrote: >>>> Let EAPI be defined as (the part behind the = of) the first line of >>>> the ebuild starting with EAPI= >>> Uh, so horribly utterly and obviously wrong. >>> >>> inherit foo >>> EAPI=4 >>> >>> where foo is both a global and a non-global eclass that sets metadata. >> >> Interesting, but quite subtly wrong. I'm surprised that you try to slip >> such an obvious logical mistake in in an attempt to save your arguments. > > Patrick, in the interest of making this comprehensible to the average > schmuck like me, which you seem to be trying to do, could you actually > explain WHY this is wrong? Otherwise it looks like you are simply trying > the arrogant "I am right because I say so" line. > AFAIK, setting EAPI has to be done before any call to inherit. Not to do so is considered a QA violation, and I believe repoman will scream at you if you do so (I could be wrong as I don't use it. If it doesn't, perhaps it should.)
Furthermore, eclasses are not supposed to set EAPI. They can test what the ebuild's EAPI is, and act accordingly, should the need arise, but they are not supposed to set it. (I'm informed this is disallowed by GLEP-55 in any event, so it's not a restriction anyone cares too much about, one would surmise.) >From conversation with Harring, who invented the whole EAPI thing, they were never meant to change very quickly. The complementary mechanism was elibs, that is files with useful library functions, which is often how eclasses are used nowadays. Eclasses in that context would be able to set EAPI, since they would effectively be a template, not a repository of functionality. (This is my no doubt flawed understanding of what he said; I'm sure he'll correct, and hopefully forgive, any errors which are of course my own.) I am curious as to why eclass versioning, which has been proposed for donkey's years, hasn't seen as much impetus as what appear from a software engineering perspective to be quite esoteric, and poorly thought-through, use-cases. There does appear to be a process issue, though resolution is another matter. Good luck with the distro. :-) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
