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

[Alan McKinnon]

On 09/12/2013 08:25, Nikos Chantziaras wrote:
> Can't come up with a more descriptive title for this one. The issue is
> this:
>
> 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.


There is no extant way to do what you want to do. USE flags operate in
isolation and their end result is strictly limited to their own scope.

Doing what you suggest leads to horrible breakage as the flag is no
longer doing what you think it is doing, it is now possibly doing
something quite different.

Portage is already doing this properly.

The correct way to deal with this (if there is such a thing) is in the
package's own build system. That so few do such things is in itself telling.


-- 
Alan McKinnon
alan.mckinnon@×××××.com