On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: > On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote > > > This whole thing is just an exercise in trying to find excuses not to > > use GLEP 55. > > A filename should not be (ab)used as a database. The main argument for > GLEP 55 is that it would make ebuild-processing generic. I.e. making > ebuild info available to whatever future ebuild processor replacement > for bash was used. A couple of comments... > > 1) Let's talk generic. Right now, we're talking about EAPI. In future, > what other (meta)data and characteristics will we need to know? What > else will be tacked onto the filename? EAPI, and any other critical > (meta)data should be declared early on in the ebuild. That's what the > ebuild is for. > > 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. Viewing it that way, this grep hack shouldn't be on the table as a viable option. ~harring
