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
signature.asc
Description: This is a digitally signed message part
