On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote: > On Tue, Mar 13, 2012 at 07:30:22AM +0000, Ciaran McCreesh wrote > > > EAPI is special. You need to know EAPI to be able to get the rest of > > the metadata. > > > > > 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. > > > > That doesn't get you the EAPI. > > On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote > > > 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. > > I'm answering Ciaran's and Brian's posts together, because the answer > is the same for both... namely, we need a 2-pass processor, regardless > of whether it's bash/perl/python/whatever. Pass 1 checks for syntax > errors and retrieves "special" variables, answering Ciaran's concern. > Today, it's EAPI. In future, there may be others. Pass 2 does the > build, assuming no errors detected in pass 1.
With respect, this statement carries no actual weight nor usefulness. PMs, by nature of dep resolution/building, already have that effective seperation. The point of this whole discussion is how to get metadata out of the ebuild w/out excessive burdens on future formats. This pass1/pass2 doesn't address that at all, nor actually relevant to the discussion at hand. Not trying to be a complete dick here, but you completely missed the points being discussed including actually responding to ciaran's point. I suggest you grab the sources of whichever PM you use, and audit how it gets metadata- it would help for understanding and contributing to this discussion. At the very least it would be useful having another person besides the Ulm/3 PM authors who actually are familiar w/ how this actually works at the core. > Under the heading of "syntax errors", I would include multiple EAPI > declarations. My response to Brian is that portage should not try to > outguess or fix or override an obviously broken ebuild. It should > return an error message (in this case "Multiple EAPI declarations not > allowed") and then halt. It is the ebuild-writer's job to come up with > a syntactically correct ebuild. And it's the PMs responsibility to enforce the rules of the environment; there in is part of the problem- portage is generally pretty lax about any form of strictness there, and has historically been that way. Even if one couldn't just point at portage, there still would be the problem of 3 different managers all needing to enforce the same tricky environment restrictions. Leaving it such that the PM has to enforce things like "don't have multiple EAPI assignments" means by default, one of them isn't going to... leading to the ebuilds breaking... specifically the common case being the ebuild becoming acclimated to some quirk of portage. EAPI was started to try and address that sensitivity (including rolling out new features), and the literal history of EAPI has involved dealing w/ quirks of portages past behaviour- including pre EAPI0. Generally speaking, the less ways something can be screwed up means less ways something *will* be screwed up. My point was that this can be pretty easily screwed up, and isn't as simple to enforce as people seem to think- that's not counting just flat out issues w/ the actual usage of it. ~brian
