Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring <ferringb@gmail.com>]

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