| 1 |
Alec Warner <antarus <at> gentoo.org> writes: |
| 2 |
|
| 3 |
> Somewhat ironically, had everyone been less stubborn last year when |
| 4 |
> discussing this topic we could have embedded the EAPI in line X of the |
| 5 |
> ebuild in 2008 and be using it now; instead of still discussing it. |
| 6 |
> |
| 7 |
> I don't expect new novel ideas out of this thread. I expect the |
| 8 |
> council to defer it again because the arguments are the same as last |
| 9 |
> time and last time they were not convincing enough. I would prefer if |
| 10 |
> the council went one way or the other so that when we are arguing |
| 11 |
> about this in 2010 we can at least say "hey we have support in |
| 12 |
> $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we |
| 13 |
> can just switch. We don't have to make the switch; I'm just saying we |
| 14 |
> should add support to hedge our bets. |
| 15 |
> |
| 16 |
> Thoughts? |
| 17 |
|
| 18 |
Well I give up. There have been exactly zero technical arguments against GLEP |
| 19 |
55 and plenty of rhetoric, but if that's enough to sway people then so be it. |
| 20 |
If we take EAPI extensions off the table, which of these would work the best |
| 21 |
(aka. gives people the warm fuzzies). |
| 22 |
|
| 23 |
- eapi in the file name, still ends in .ebuild |
| 24 |
-- no parsing needed |
| 25 |
-- doesn't allow version suffix additions/changes |
| 26 |
-- requires an initial wait period for PM's to implement support and be |
| 27 |
stabilized |
| 28 |
-- still makes some people grumpy/threaten to leave |
| 29 |
|
| 30 |
- eapi in the ebuild, on a predetermined line number |
| 31 |
-- error prone, restrictive |
| 32 |
-- doesn't require parsing |
| 33 |
-- doesn't allow version suffix additions/changes |
| 34 |
|
| 35 |
- eapi in the ebuild, anywhere |
| 36 |
-- what we have now |
| 37 |
-- currently requires sourcing the ebuild |
| 38 |
-- sourcing the ebuild requires knowing the EAPI |
| 39 |
-- doesn't allow version suffix additions/changes (actually, none of these do, |
| 40 |
so i'll stop repeating it) |
| 41 |
|
| 42 |
- eapi in the ebuild, before any other assignments/commands |
| 43 |
-- ie. if we hit inherit and no EAPI is defined, EAPI=0 |
| 44 |
-- restrictive (eapi must be a direct assignment, no conditionals, etc) |
| 45 |
-- no per category/PN eapi's or eapi's set in eclasses |
| 46 |
-- probably the next best solution (IMUO) |
| 47 |
|
| 48 |
- eapi in metadata somewhere else |
| 49 |
-- meh, i'll let the proponents of this argue for it |
| 50 |
|
| 51 |
please fill your arguments for or against, or fix whatever i have wrong. |
| 52 |
|
| 53 |
some other random ideas i've seen tossed around: |
| 54 |
- #!/bin/env eapi-parser |
| 55 |
- split EAPI into EAPI and some separate counter which would only be |
| 56 |
incremented on uncompatible changes to the ebuild format |
| 57 |
- change .ebuild to .eb |
| 58 |
- waffles (sorry, lunchtime) |
Archives