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