| 1 |
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote: |
| 2 |
[...] |
| 3 |
> So if you were a lazy Unix coder you'd just restrict the current rules a bit |
| 4 |
> so that there's only one line starting with EAPI= allowed (or maybe you just |
| 5 |
> take the first or last one, but that's annoying) and if no such line matches |
| 6 |
> you can safely assume EAPI0 |
| 7 |
> |
| 8 |
> Maybe you're very lazy, so you explicitly forbid eclasses from setting or |
| 9 |
> changing EAPI. That also avoids weird effects that make you lose lots of time |
| 10 |
> for debugging because you didn't think about what would happen if foo.eclass |
| 11 |
> set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ... |
| 12 |
> |
| 13 |
> And magically you haven't really changed current behaviour, can get the EAPI |
| 14 |
> without sourcing it and you can be lazy once more. Isn't it great? |
| 15 |
|
| 16 |
As I've stated a long time ago, I'm for this solution. My understanding |
| 17 |
is that there are 2 objections to this: |
| 18 |
|
| 19 |
1) We can't change the ebuild format to XML or what have you. I think |
| 20 |
this is a problem to deal with *if it ever happens*. I am completely |
| 21 |
against trying to solve a problem that will not exist in the foreseeable |
| 22 |
future. |
| 23 |
|
| 24 |
2) There might be a performance impact for cases where the metadata is |
| 25 |
uncached - I think the impact is acceptable in the face of the fugliness |
| 26 |
added by putting the EAPI in the ebuild's name (Joe Peterson summarise |
| 27 |
this quite well earlier [1]). |
| 28 |
|
| 29 |
Really, the key issue seems to be (1), because there's no other good |
| 30 |
reason to be trying to adopt this GLEP. |
| 31 |
|
| 32 |
-- Arun |
| 33 |
|
| 34 |
[1] |
| 35 |
http://www.mail-archive.com/gentoo-dev@l.g.o/msg29311.html |
Archives