On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
<ciaran.mccreesh@...> wrote:
> On Mon, 23 Feb 2009 08:43:09 -0700
> Steve Dibb <beandog@g.o> 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"

This is not legal, the devmanual[1] explicitly states that it is not
legal to set EAPI in an eclass.  If it was you would have an open and
shut case for g55 (since you could set EAPI based on PV in an eclass
and then inherit the eapi; requiring a bash parser).  But its illegal,
which makes your argument harder.

A bad argument is EAPI based on some PV logic that you can copy across
ebuilds that differ by version; which would fall into 'stupid' in my
book.

[1] http://devmanual.gentoo.org/ebuild-writing/eapi/index.html

>
> 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"

Also illegal, but I assume here you intend to change the legality of
things in your weird future example.

>
> 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
>