Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

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

On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb <beandog@gentoo.org> wrote:
> Plus, I don't really grasp the whole "we have to source the whole
> ebuild to know the EAPI version" argument.  It's one variable, in one
> line. Can't a simple parser get that and go from there?

Not true. This is entirely legal:

In pkg-1.ebuild:

    EAPI="${PV}"
    printf -v EAPI '%s' 4
    inherit foo
    EAPI="2"

In foo.eclass:

    EAPI="3"

And in this case, the package manager has to know that EAPI=2, and it
has to use EAPI 2's behaviour for performing the inherit.

In fact, it gets worse if you consider that future EAPIs will probably
allow per-package eclasses. So you could end up with this crazy
situation:

In pkg-1.ebuild:

    require pkg

In cat/pkg/pkg.eclass:

    EAPI="3"

In global pkg.eclass:

    EAPI="2"

So here you can't even use a faked pre-source EAPI. If you assume EAPI
0 beforehand, the global pkg.eclass will be used, so EAPI will end up
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be
used, so the EAPI will end up as 3.

It gets even crazier if you put EAPI="2" in the per-pkg eclass and
EAPI="3" in the global one instead...

And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.

-- 
Ciaran McCreesh

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