[gentoo-dev] Re: The fallacies of GLEP55

[Steven J Long]

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 <patrick@g.o> 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 ;-)