[gentoo-user] Re: Any good way to pick global USE flag alternatives?

[eroen]

On Mon, 09 Dec 2013 08:25:19 +0200
Nikos Chantziaras <realnc@×××××.com> wrote:

> There are some global USE flags that allow users to pick alternative
> methods of implementing the same thing. For example, packages that
> offer a GUI might do so through the "qt" or "gtk" USE flag. Or audio
> support, where you can choose "alsa" or "pulseaudio".
>
> Now, if I wanted to, for example, always choose PulseAudio support
> instead of ALSA and a Qt GUI instead of a Gtk+ one, one would think
> that I could just do:
>
>    USE="pulseaudio qt -alsa -gtk"
>
> in my make.conf. But, that doesn't work. That's because some packages
> don't offer an alternative at all. Some package might only support
> ALSA for audio, and disabling that would lead to the package not
> offering any audio output at all. Or it might only offer a Gtk+ GUI,
> not a Qt one, and disabling the "gtk" flag will make the package not
> building its GUI component at all.
>
> So what's needed here, is a way to tell Portage to only disable a
> global USE flag for packages that also offer another one, specified
> by the user. Like this pseudo make.conf syntax:
>
>    USE="pulseaudio pulseaudio?(-alsa) qt qt?(-gtk)"
>
> Is something like this already possible? Right now, the only way to
> painstakingly go through every single package that comes up on an
> 'USE=use_flags_here emerge -pDN @world' and insert them individually
> into package.use.
>
> There should be a proper way of doing this.

I like this idea, I think it could be especially useful in the context
of PYTHON_SINGLE_TARGET.

I'm not sure I like all the details in the suggestion, though. In
particular, the flags you mention have widely varying meaning throughout
the tree, for example mkvtoolnix has wxwidgets and qt4 use flags that
enable independent and completely different things.

Perhaps it would be better to implement this as a new analogue to
USE_EXPAND always expands to the first item in the user configuration
that is also in IUSE for the package? This would then exclusively be
used for "pick one of these options" style settings, like the gui of
*some* packages, TLS implemetation, PYTHON_SINGLE_TARGET and so on.

I think this could be preferable to the many packages that currently
just arbitrarily picks one choice when two mutually exclusive flags are
enabled. It might be necessary to expand this with some form of "light
masking" for ebuilds that want to *strongly* suggest one choice over
another.

Example:
User sets (in make.conf):
    TLS_IMPL_PREF="openssl gnutls"

Ebuild with IUSE="tls_impl_pref_gnutls tls_impl_pref_openssl" sees
tls_impl_pref_gnutls as disabled and tls_impl_pref_openssl as enabled.

Ebuild with IUSE="tls_impl_pref_gnutls" sees tls_impl_pref_gnutls as
enabled.

-- 
eroen