Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 01/06/16 10:13 PM, waltdnes@××××××××.org wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
>> waltdnes@××××××××.org wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
>
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
>


The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
>
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
>
> Level 1) GUI
>
> Level 2) X or xorg or Wayland or Mir
>
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk


1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


>
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...