1 |
Hello all, |
2 |
|
3 |
To shove under the rug: |
4 |
|
5 |
Bug 62001: Have portage QA checks consider USE_EXPAND |
6 |
Bug 70648: QA warnings about USE_EXPAND-derived use variables |
7 |
Bug 101998: Portage shouldn't warn on missing IUSE for USE_EXPAND |
8 |
|
9 |
To not shove under the rug: |
10 |
|
11 |
Bug 23826: Give more visibility to ebuilds variables (ALSA_CARDS, etc.) |
12 |
Bug 65012: emerge should display USE_EXPAND flags when using --verbose and |
13 |
--pretend (or --ask) |
14 |
|
15 |
The above are only when searching for USE_EXPAND in the summary field. |
16 |
|
17 |
|
18 |
So let's step back a bit and look at the purpose of the QA check first. What |
19 |
it does is check whether an ebuild is utilizing a USE flag that it has not |
20 |
declared. Why does this matter for QA? It means that users are not informed |
21 |
of what options affect the package. It also means the same for portage, which |
22 |
will become more and more important as time goes on. |
23 |
|
24 |
Removing the QA check while the QA problem still exists is, in my mind, just |
25 |
plain ludicrous. Removing the QA check once the QA problem is fixed doesn't |
26 |
make much sense to me either. However, adjusting the check where necessary to |
27 |
match the fix is reasonable. |
28 |
|
29 |
So what needs to be done to fix it? Well, what is the purpose of USE_EXPAND? |
30 |
Put simply, it is to allow the user to select one or more features of a |
31 |
package from a list of choices. How is this different to USE flags? The |
32 |
choices all pertain to one aspect of the package(s). |
33 |
|
34 |
Beyond that is where we start to run into the gray murkiness that has been |
35 |
created due to having no policy on USE_EXPAND. |
36 |
|
37 |
1) What to do if nothing is set? |
38 |
2) What to do if an invalid value is set? |
39 |
|
40 |
a) install everything |
41 |
b) install nothing |
42 |
c) install some predefined default |
43 |
d) install some default based on USE flags |
44 |
e) die and tell the user to make a choice |
45 |
|
46 |
3) How to ebuild behave regarding a USE_EXPAND variable? |
47 |
|
48 |
a) install everything chosen that is valid |
49 |
b) install only the first that is chosen that is valid |
50 |
|
51 |
Of these, 1) and 2) absolutely must be whittled down to one standard. |
52 |
Preferably, 3) should follow one standard as well. Not following one standard |
53 |
will simply lead to users thinking, "but that's not what I wanted..!" It will |
54 |
also lead portage to do needless recompiles due to the information available |
55 |
being limited. |
56 |
|
57 |
Next, storing the information of what choices are valid. If it can be |
58 |
guaranteed that all packages supporting a variable (LINGUAS for example) have |
59 |
exactly the same list of choices in all cases, storing the choice list in a |
60 |
global file is acceptable. If not, each package absolutely must list what |
61 |
choices are available for it. Not doing so means the flow may head into 2) in |
62 |
the above list even when the user has set a valid choice for a different |
63 |
package. Again, it's against the user's expectations. |
64 |
|
65 |
Anybody not caring enough to fix this, please don't respond with "wah! work!?" |
66 |
You've dug your own hole... |
67 |
|
68 |
-- |
69 |
Jason Stubbs |
70 |
-- |
71 |
gentoo-dev@g.o mailing list |