Re: [gentoo-dev] Re: The fallacies of GLEP55

[David Leverton <levertond@googlemail.com>]

On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote:
> I thought we had agreed that (1) with GLEP55 you have to source the ebuild
> anyway (whereas the other proposal allows to just parse it to get at the
> EAPI value) and (2) you can cache it sanely so that performance isn't the
> issue?

You don't /have/ to source the ebuild to get the EAPI for GLEP 55.  That 
section is only there to cover corner cases that some people wanted to be 
well-defined, and it could easily be removed if the consensus is that that 
isn't a problem.  On the other hand, it could equally well be added to 
whatever alternative solution you might suggest.

Consider the case where you have a foo-1.2.ebuild-4, and in the contents of 
the file it sets EAPI=5.  What should that mean?  There are three 
possibilities that I can think of:

1) It's illegal, don't do that.  Then there's no need to source the file to 
find the EAPI, because the corner case should never happen, and if it does, 
the behaviour can be left undefined.

2) It's legal, and the ebuild has EAPI 4.  Then there's no need to source the 
file to find the EAPI, because the EAPI in the filename always wins.

3) It's legal, and the ebuild has EAPI 5.  This requires sourcing the ebuild 
to find the EAPI, and it's what GLEP 55 currently says.

Now consider the alternative fixed-format "^EAPI=" suggestion.  What if we 
have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 
further down?  What should that mean?  The same three possibilities apply 
here as in the GLEP 55 case.  If you think it should be illegal, or that it 
should mean EAPI=4, then there's no need to source the ebuild just to find 
the EAPI.  If you think it should mean EAPI=5, then you do need to source the 
ebuild, exactly the same as in GLEP 55.

Either way, this isn't a valid reason to choose the fixed-format alternative 
over GLEP 55, because the same concerns do or do not apply to both.