Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 431408 - [Future EAPI] USE_EXPAND should be possible per package
Summary: [Future EAPI] USE_EXPAND should be possible per package
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal enhancement with 1 vote (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2012-08-14 17:04 UTC by Martin Väth
Modified: 2020-10-25 16:35 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2012-08-14 17:04:57 UTC
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.
Comment 1 Tiziano Müller (RETIRED) gentoo-dev 2013-06-18 09:42:47 UTC
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"


  <expand name="other_plugins>
    <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.