1 |
On Thu, 2012-09-13 at 03:39 -0700, Brian Harring wrote: |
2 |
> Hola. |
3 |
> |
4 |
> CC'ing pms since obviously they should comment, although the |
5 |
> discussion should be on -dev (aka, public, not an alias). |
6 |
> |
7 |
> Sorry, this is a long email; condensing it down into a glep is viable, |
8 |
> just my time is limited (it's telling I started the gentoo stuff at |
9 |
> 2am, wrapping up likely at 4am). |
10 |
> |
11 |
> The length of this email basically relates to the subtlety of this |
12 |
> proposal; at first glance it may appear as if I'm proposing a syntax |
13 |
> shuffle just for aesthetic reasons, but as elaborated in the tail end, |
14 |
> that subtle syntax change opens up a lot of possibilities. |
15 |
> |
16 |
> |
17 |
> Either way, what I propose, is pretty simple. Currently USE_EXPAND'd |
18 |
> groups are pushed into USE in the form ${use_group}_${setting}. |
19 |
> |
20 |
> Thus VIDEO_CARDS="intel nvidia" becomes video_cards_intel |
21 |
> video_cards_nvidia. This should be reasonably well known and |
22 |
> understood from the dev standpoint; from the PM side of things, this |
23 |
> actually seriously sucks ass; if we see video_cards_intel in an IUSE |
24 |
> somewhere, we don't know if it's a USE flag, or a use_expanded group; |
25 |
> to figure that out, we basically have to do a longest prefix matching |
26 |
> (or suffix tree). |
27 |
> |
28 |
> There in is one of the subtle design flaws of it; two USE_EXPAND'd |
29 |
> targets, VIDEO_CARDS and VIDEO, can intersect in their namespace. |
30 |
> While we (devs) intentionally avoid this potential via careful name |
31 |
> choice, the fact the possibility exists is a bit of a sign that |
32 |
> USE_EXPAND was a bit of a hack. |
33 |
> |
34 |
> What I propose is simple enough, and is for >=EAPI5: |
35 |
> |
36 |
> 1) We disallow '@' in USE flags (yes, a use flag can actually have |
37 |
> '@' in it's name according to PMS; someone was hitting the crack |
38 |
> pipe pretty damn hard when they allowed that one). This doesn't |
39 |
> impact anything in gentoo-x86, nor any tree I've ever seen. |
40 |
> |
41 |
> 2) If <EAPI5, we continue exporting video_cards_nvidia |
42 |
> (${use_group}_${setting}). |
43 |
> |
44 |
> 3) If >=EAPI5, we export ${use_group}_${setting}, *and* |
45 |
> ${use_group}@${setting}. While there may be complaints about having |
46 |
> it exported in two fashions, the reason for this is simple- it makaes |
47 |
> transition way the fuck easier, meaning we don't make devs wrie pain |
48 |
> in the ass "if eapi x, else blah" code. Basically, for eclass code, |
49 |
> the dev would do thus: |
50 |
> 3.a) If the eclass supports <EAPI5, they check for the old form; |
51 |
> ${use_group}_${setting}. |
52 |
> 3.b) If however that eclass is >=EAPI5, they should check for the new |
53 |
> form; ${use_group}@{setting}. |
54 |
> |
55 |
> 4) At some point in the future, when either code involved has migrated |
56 |
> all to EAPI5, or we do something in a later EAPI that renders |
57 |
> supporting ${use_group}_${setting} untenuable, we stop exporting |
58 |
> ${use_group}_${setting} for those EAPIs. Preferably with one EAPI |
59 |
> cycle w/ deprecation warnings. |
60 |
> |
61 |
... |
62 |
> ~harring |
63 |
> |
64 |
|
65 |
+1 |
66 |
|
67 |
This would make things easier for PM consumer apps to process use flags |
68 |
without specialized code to figure out if the flag was use_expanded or |
69 |
just had an "_" in it's name... |
70 |
|
71 |
-- |
72 |
Brian Dolbec <dolsen@g.o> |