Hello all,
To shove under the rug:
Bug 62001: Have portage QA checks consider USE_EXPAND
Bug 70648: QA warnings about USE_EXPAND-derived use variables
Bug 101998: Portage shouldn't warn on missing IUSE for USE_EXPAND
To not shove under the rug:
Bug 23826: Give more visibility to ebuilds variables (ALSA_CARDS, etc.)
Bug 65012: emerge should display USE_EXPAND flags when using --verbose and
--pretend (or --ask)
The above are only when searching for USE_EXPAND in the summary field.
So let's step back a bit and look at the purpose of the QA check first. What
it does is check whether an ebuild is utilizing a USE flag that it has not
declared. Why does this matter for QA? It means that users are not informed
of what options affect the package. It also means the same for portage, which
will become more and more important as time goes on.
Removing the QA check while the QA problem still exists is, in my mind, just
plain ludicrous. Removing the QA check once the QA problem is fixed doesn't
make much sense to me either. However, adjusting the check where necessary to
match the fix is reasonable.
So what needs to be done to fix it? Well, what is the purpose of USE_EXPAND?
Put simply, it is to allow the user to select one or more features of a
package from a list of choices. How is this different to USE flags? The
choices all pertain to one aspect of the package(s).
Beyond that is where we start to run into the gray murkiness that has been
created due to having no policy on USE_EXPAND.
1) What to do if nothing is set?
2) What to do if an invalid value is set?
a) install everything
b) install nothing
c) install some predefined default
d) install some default based on USE flags
e) die and tell the user to make a choice
3) How to ebuild behave regarding a USE_EXPAND variable?
a) install everything chosen that is valid
b) install only the first that is chosen that is valid
Of these, 1) and 2) absolutely must be whittled down to one standard.
Preferably, 3) should follow one standard as well. Not following one standard
will simply lead to users thinking, "but that's not what I wanted..!" It will
also lead portage to do needless recompiles due to the information available
being limited.
Next, storing the information of what choices are valid. If it can be
guaranteed that all packages supporting a variable (LINGUAS for example) have
exactly the same list of choices in all cases, storing the choice list in a
global file is acceptable. If not, each package absolutely must list what
choices are available for it. Not doing so means the flow may head into 2) in
the above list even when the user has set a valid choice for a different
package. Again, it's against the user's expectations.
Anybody not caring enough to fix this, please don't respond with "wah! work!?"
You've dug your own hole...
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
