I realized the following when I wrote an ebuild which "naturally"
could need a huge string to decide which submodules to install
(app-shells/zsh from the mv overlay, but this example is not crucial):
A clean way to implement this in ebuilds is to specify (in this example):
USE="[other USE flags] completion_... completion_.... completion_..."
and to set
However, logically, this USE_EXPAND should be part of the ebuild,
and, logically, it should even be local to the ebuild:
If some other package by accident has a flag which starts with
"completion_", it is not reasonable that this package is also subject to
the USE_EXPAND, just because another package needs such a list.
Also when I think about the current main examples of USE_EXPAND
(APACHE2_MODULES, ALSA_CARDS, VIDEO_CARDS, etc), it is always the
corresponding _ebuilds_ which logically should know that they want
USE_EXPAND variables. So setting them profile wide makes not so much
sense for these IMHO.
There are some exceptions like LINGUAS for which it would not
be convenient to specify them in every ebuild, so it makes sense
to keep some profile wide USE_EXPAND settings.
However, being able to define USE_EXPAND "locally" in a
particular package seems like a natural enhancement to me
and could be implemented in some future ebuild EAPI without breaking
any compatibility with the current behavior.
that variable would need metadata caching again, instead, one could squeeze it into IUSE pretty nicely (see also bug #471776) which also avoids repetition:
IUSE="regular_flag language_plugins: php ruby python other_plugins: foo bar baz"
<flag name="foo">enable foo</flag>
and to solve bug #133327 one could then write a simple parser to extract IUSE_OTHER_PLUGINS from the IUSE, either in PMS or in an eclass.