On 06/02/2016 08:08 AM, Raymond Jennings wrote: > 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.
How do you decide which one package B builds in such a case? Honestly, I don't think this is a good idea. The rationale and suggested implementation just don't bring enough benefit in my opinion. Often times it's hard enough to research a reported issue with the current implementation. Having a flag like 'gui' whose behavior (potentially) changes based on what profile is being used makes things considerably harder. It would no longer be a simple matter of matching versions and USE flags, the package maintainer would also need to setup an equivalent system with the same profile or research what the 'gui' flag with profile 'x' does and setup an equivalent USE flag set. Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly do the same thing. The only thing they don't do (as I understand the profiles) is enable GUI support for packages that don't support the preferred libraries. Is that really enough justification to implement this flag? As a maintainer I'd ask that, at the very least, a more compelling reason than "it's too annoying to update package.use" is given. I find the argument against putting all the flags in global a valid but weak as there are already mitigations for that scenario. Perhaps I'm missing something, but I'm not convinced this will provide a significant enough benefit to the average Gentoo user to offset the increased troubleshooting demand it'll put on Gentoo's developers, maintainers, and proxy-maintainers. Thanks, Nicholas Vinson P.S. I'd also like to add that I do spend a considerable amount of time in #gentoo and I don't recall seeing this problem come up that much. The closest I've seen was a user asking where /usr/bin/VirtualBox was (as it only gets installed when the proper qt USE flag is set), but based on personal experience that happens maybe 1 or 2 every 3 - 4 months (if that often). > > On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius <a...@gentoo.org > <mailto:a...@gentoo.org>> wrote: > > On 01/06/16 10:13 PM, waltd...@waltdnes.org > <mailto:waltd...@waltdnes.org> wrote: > > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote > > > >> waltd...@waltdnes.org <mailto: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* ... > > > > >
signature.asc
Description: OpenPGP digital signature
