On 03/13/2012 12:03 AM, Brian Harring wrote: > On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: >> 2) Any potential ebuild processor that's incapable of looking for regex >> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no >> business being used to process ebuilds. > > Perfectly valid, if stupid, bash: > > EAPI=3 > EAPI=4 > > Which is the PM to choose? Because if your answer is "the first", > then you need to keep in mind that any following code (including > eclasses that test eapi) will be seeing the second during sourcing. > Nice little gotcha, that one. > > I'm aware people have suggested "make EAPI readonly" to try and deal > w/ this; that however means it'll break any PM that uses eval for > loading the ebuild, and means that every ebuild sourcing for phase > running will throw a complaint about EAPI being readonly. > > I don't hugely expect PMs to screw up the ordering of which to chose, > although it exists; trying to ban secondary settings is also an > approach... but all of it points to the fact it's a fricking hack and > isn't really worth doing. > > If we're going to redo EAPI, redo it right. Don't half ass it- this > time around we're not forced to make compromises.
The "parse EAPI assignment" approach is more about fixing EAPI than redoing it. It's the least invasive approach, and it would work perfectly well in practice. Issues like the invalid double assignment that you mentioned, which are pretty unlikely anyway, are easily handled if package manager implements a feedback mechanism to assert that the parsed EAPI is identical to the value obtained from bash [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18 -- Thanks, Zac
