use case: Telling a package to build a gui without deciding which one to build. Also helps in cases where you have package A that can only build a qt gui, and package B that can build both qt and gtk, and package C that can build gtk only. You want to have a gui for all three, but you don't want to hav epackage B build both guis and at the same time while you may prefer qt, you don't want to leave package C without a gui.
On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius <a...@gentoo.org> wrote: > On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote: > > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote > > > >> waltd...@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* ... > > > > >
