1 |
On Sun, Sep 30, 2012 at 12:52:40PM -0700, Zac Medico wrote: |
2 |
> On 09/30/2012 12:44 PM, Brian Harring wrote: |
3 |
> > tries to write a PM, likely fucking that up. If what you were saying |
4 |
> > was the actual intention behind it, that assignment would've just been |
5 |
> > along the lines of EAPI=("[^"]*"|'[^']*'|[^\t ]); aka "here's how you |
6 |
> > grab what looks like an EAPI assignment". |
7 |
> |
8 |
> I would have preferred a regex that just matches any assignment like |
9 |
> this, but didn't feel like bikeshedding it, since the one that's |
10 |
> currently in the spec works in practice. |
11 |
|
12 |
Counter point; portage doesn't actually enforce the rules of a valid |
13 |
EAPI name; correct me if I'm wrong obviously, but in checking the |
14 |
source, didn't see any such validation. |
15 |
|
16 |
If the regex were as I suggested, that would be a non issue and we'd |
17 |
have *guranteed* EAPI name compliance- else it wouldn't match the |
18 |
invalid EAPI, and would stop looking at that line (falling back to |
19 |
EAPI=0). |
20 |
|
21 |
Basically, I'd like y'all to spell out the actual gains of having it |
22 |
loose like this, especailly in light of the fact the majority PM, via |
23 |
relying on that alone, doesn't do EAPI value enforcement. |
24 |
|
25 |
If we used the regex I suggested in the second email, this issue goes |
26 |
away, and we remove a potential landmine. |
27 |
|
28 |
Clarify to me why that landmine should be left in place. |
29 |
|
30 |
~harring |