1 |
On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: |
2 |
> On Mon, Mar 12, 2012 at 05:12:28PM +0000, Ciaran McCreesh wrote |
3 |
> |
4 |
> > This whole thing is just an exercise in trying to find excuses not to |
5 |
> > use GLEP 55. |
6 |
> |
7 |
> A filename should not be (ab)used as a database. The main argument for |
8 |
> GLEP 55 is that it would make ebuild-processing generic. I.e. making |
9 |
> ebuild info available to whatever future ebuild processor replacement |
10 |
> for bash was used. A couple of comments... |
11 |
> |
12 |
> 1) Let's talk generic. Right now, we're talking about EAPI. In future, |
13 |
> what other (meta)data and characteristics will we need to know? What |
14 |
> else will be tacked onto the filename? EAPI, and any other critical |
15 |
> (meta)data should be declared early on in the ebuild. That's what the |
16 |
> ebuild is for. |
17 |
> |
18 |
> 2) Any potential ebuild processor that's incapable of looking for regex |
19 |
> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no |
20 |
> business being used to process ebuilds. |
21 |
|
22 |
Perfectly valid, if stupid, bash: |
23 |
|
24 |
EAPI=3 |
25 |
EAPI=4 |
26 |
|
27 |
Which is the PM to choose? Because if your answer is "the first", |
28 |
then you need to keep in mind that any following code (including |
29 |
eclasses that test eapi) will be seeing the second during sourcing. |
30 |
Nice little gotcha, that one. |
31 |
|
32 |
I'm aware people have suggested "make EAPI readonly" to try and deal |
33 |
w/ this; that however means it'll break any PM that uses eval for |
34 |
loading the ebuild, and means that every ebuild sourcing for phase |
35 |
running will throw a complaint about EAPI being readonly. |
36 |
|
37 |
I don't hugely expect PMs to screw up the ordering of which to chose, |
38 |
although it exists; trying to ban secondary settings is also an |
39 |
approach... but all of it points to the fact it's a fricking hack and |
40 |
isn't really worth doing. |
41 |
|
42 |
If we're going to redo EAPI, redo it right. Don't half ass it- this |
43 |
time around we're not forced to make compromises. |
44 |
|
45 |
Viewing it that way, this grep hack shouldn't be on the table as a |
46 |
viable option. |
47 |
|
48 |
~harring |