On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote:
[...]
> So if you were a lazy Unix coder you'd just restrict the current rules a bit 
> so that there's only one line starting with EAPI= allowed (or maybe you just 
> take the first or last one, but that's annoying) and if no such line matches 
> you can safely assume EAPI0
> 
> Maybe you're very lazy, so you explicitly forbid eclasses from setting or 
> changing EAPI. That also avoids weird effects that make you lose lots of time 
> for debugging because you didn't think about what would happen if foo.eclass 
> set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ...
> 
> And magically you haven't really changed current behaviour, can get the EAPI 
> without sourcing it and you can be lazy once more. Isn't it great?

As I've stated a long time ago, I'm for this solution. My understanding
is that there are 2 objections to this:

1) We can't change the ebuild format to XML or what have you. I think
this is a problem to deal with *if it ever happens*. I am completely
against trying to solve a problem that will not exist in the foreseeable
future.

2) There might be a performance impact for cases where the metadata is
uncached - I think the impact is acceptable in the face of the fugliness
added by putting the EAPI in the ebuild's name (Joe Peterson summarise
this quite well earlier [1]).

Really, the key issue seems to be (1), because there's no other good
reason to be trying to adopt this GLEP.

-- Arun

[1]
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg29311.html