1 |
On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote: |
2 |
> On Tue, Mar 13, 2012 at 07:30:22AM +0000, Ciaran McCreesh wrote |
3 |
> |
4 |
> > EAPI is special. You need to know EAPI to be able to get the rest of |
5 |
> > the metadata. |
6 |
> > |
7 |
> > > 2) Any potential ebuild processor that's incapable of looking for |
8 |
> > > regex "^EAPI=" in a textfile, amd parsing the numbers that follow, |
9 |
> > > has no business being used to process ebuilds. |
10 |
> > |
11 |
> > That doesn't get you the EAPI. |
12 |
> |
13 |
> On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote |
14 |
> |
15 |
> > Perfectly valid, if stupid, bash: |
16 |
> > |
17 |
> > EAPI=3 |
18 |
> > EAPI=4 |
19 |
> > |
20 |
> > Which is the PM to choose? Because if your answer is "the first", |
21 |
> > then you need to keep in mind that any following code (including |
22 |
> > eclasses that test eapi) will be seeing the second during sourcing. |
23 |
> > Nice little gotcha, that one. |
24 |
> > |
25 |
> > I'm aware people have suggested "make EAPI readonly" to try and deal |
26 |
> > w/ this; that however means it'll break any PM that uses eval for |
27 |
> > loading the ebuild, and means that every ebuild sourcing for phase |
28 |
> > running will throw a complaint about EAPI being readonly. |
29 |
> > |
30 |
> > I don't hugely expect PMs to screw up the ordering of which to chose, |
31 |
> > although it exists; trying to ban secondary settings is also an |
32 |
> > approach... but all of it points to the fact it's a fricking hack and |
33 |
> > isn't really worth doing. |
34 |
> |
35 |
> I'm answering Ciaran's and Brian's posts together, because the answer |
36 |
> is the same for both... namely, we need a 2-pass processor, regardless |
37 |
> of whether it's bash/perl/python/whatever. Pass 1 checks for syntax |
38 |
> errors and retrieves "special" variables, answering Ciaran's concern. |
39 |
> Today, it's EAPI. In future, there may be others. Pass 2 does the |
40 |
> build, assuming no errors detected in pass 1. |
41 |
|
42 |
With respect, this statement carries no actual weight nor usefulness. |
43 |
PMs, by nature of dep resolution/building, already have that effective |
44 |
seperation. |
45 |
|
46 |
The point of this whole discussion is how to get metadata out of the |
47 |
ebuild w/out excessive burdens on future formats. This pass1/pass2 |
48 |
doesn't address that at all, nor actually relevant to the discussion |
49 |
at hand. Not trying to be a complete dick here, but you completely |
50 |
missed the points being discussed including actually responding to |
51 |
ciaran's point. |
52 |
|
53 |
I suggest you grab the sources of whichever PM you use, and audit how |
54 |
it gets metadata- it would help for understanding and contributing to |
55 |
this discussion. At the very least it would be useful having another |
56 |
person besides the Ulm/3 PM authors who actually are familiar w/ how |
57 |
this actually works at the core. |
58 |
|
59 |
|
60 |
> Under the heading of "syntax errors", I would include multiple EAPI |
61 |
> declarations. My response to Brian is that portage should not try to |
62 |
> outguess or fix or override an obviously broken ebuild. It should |
63 |
> return an error message (in this case "Multiple EAPI declarations not |
64 |
> allowed") and then halt. It is the ebuild-writer's job to come up with |
65 |
> a syntactically correct ebuild. |
66 |
|
67 |
And it's the PMs responsibility to enforce the rules of the |
68 |
environment; there in is part of the problem- portage is generally |
69 |
pretty lax about any form of strictness there, and has historically |
70 |
been that way. Even if one couldn't just point at portage, there |
71 |
still would be the problem of 3 different managers all needing to |
72 |
enforce the same tricky environment restrictions. |
73 |
|
74 |
Leaving it such that the PM has to enforce things like "don't have |
75 |
multiple EAPI assignments" means by default, one of them isn't going |
76 |
to... leading to the ebuilds breaking... specifically the common case |
77 |
being the ebuild becoming acclimated to some quirk of portage. EAPI |
78 |
was started to try and address that sensitivity (including rolling out |
79 |
new features), and the literal history of EAPI has involved dealing w/ |
80 |
quirks of portages past behaviour- including pre EAPI0. |
81 |
|
82 |
Generally speaking, the less ways something can be screwed up means |
83 |
less ways something *will* be screwed up. |
84 |
|
85 |
My point was that this can be pretty easily screwed up, and isn't as |
86 |
simple to enforce as people seem to think- that's not counting just |
87 |
flat out issues w/ the actual usage of it. |
88 |
|
89 |
~brian |