1 |
On 03/13/2012 12:03 AM, Brian Harring wrote: |
2 |
> On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: |
3 |
>> 2) Any potential ebuild processor that's incapable of looking for regex |
4 |
>> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no |
5 |
>> business being used to process ebuilds. |
6 |
> |
7 |
> Perfectly valid, if stupid, bash: |
8 |
> |
9 |
> EAPI=3 |
10 |
> EAPI=4 |
11 |
> |
12 |
> Which is the PM to choose? Because if your answer is "the first", |
13 |
> then you need to keep in mind that any following code (including |
14 |
> eclasses that test eapi) will be seeing the second during sourcing. |
15 |
> Nice little gotcha, that one. |
16 |
> |
17 |
> I'm aware people have suggested "make EAPI readonly" to try and deal |
18 |
> w/ this; that however means it'll break any PM that uses eval for |
19 |
> loading the ebuild, and means that every ebuild sourcing for phase |
20 |
> running will throw a complaint about EAPI being readonly. |
21 |
> |
22 |
> I don't hugely expect PMs to screw up the ordering of which to chose, |
23 |
> although it exists; trying to ban secondary settings is also an |
24 |
> approach... but all of it points to the fact it's a fricking hack and |
25 |
> isn't really worth doing. |
26 |
> |
27 |
> If we're going to redo EAPI, redo it right. Don't half ass it- this |
28 |
> time around we're not forced to make compromises. |
29 |
|
30 |
The "parse EAPI assignment" approach is more about fixing EAPI than |
31 |
redoing it. It's the least invasive approach, and it would work |
32 |
perfectly well in practice. Issues like the invalid double assignment |
33 |
that you mentioned, which are pretty unlikely anyway, are easily handled |
34 |
if package manager implements a feedback mechanism to assert that the |
35 |
parsed EAPI is identical to the value obtained from bash [1]. |
36 |
|
37 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18 |
38 |
-- |
39 |
Thanks, |
40 |
Zac |