Raymond Jennings posted on Fri, 11 Sep 2015 21:55:46 -0700 as excerpted: > On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman <ri...@gentoo.org> wrote: > >> USE=gui or something like that if the main effect is to have a gui or >> not. That is the sort of thing that SHOULD go in make.conf or in a >> profile. If disabling gtk makes it a console-only application then use >> the gui flag. >> >> USE=gtk if the main effect is to select /which/ toolkit is used if more >> than one is optionally supported. That /might/ go in a make.conf or >> profile, but probably shouldn't in general. It is more appropriate for >> something like the desktop/gnome profile than the desktop profile. >> >> USE=gtk# if you're picking which version to use. That should /almost >> never/ go in a profile (unless you're talking about a testing profile >> of some kind, such as on an overlay), or in a global config unless you >> REALLY know what you're getting into. Users setting this globally >> should expect to run into bugs. The package should default these flags >> to whatever is most appropriate for the specific package. >> > I really like this approach, and I think that having tiers of > (gui)->(qt/gtk)->(qt4/qt5//gtk2/gtk3) would go a long way to keeping USE > flags coherent.
The other possibility, which I haven't seen raised but if we're going to examine the options I think we at least need this on record as having been discussed, is... Just bite the bullet and create entire USE flag families such that an ebuild can choose the flag appropriate to how it actually uses it. AFAIK this would need EAPI help, for reasons given below, but it should be doable. gui gui-gtk gui-gtk-2 gui-gtk-3 gui-qt gui-qt-4 gui-qt-5 (Do we want X and wayland variants of the above?) req-alt-gtk req-alt-gtk-2 req-alt-gtk-3 req-alt-qt req-alt-qt-4 req-alt-qt-5 choice-alt-gtk choice-alt-gtk-2 choice-alt-gtk-3 choice-alt-qt choice-alt-qt-4 choice-alt-qt-5 ... Then people could set in make.conf something like... USE="gui -gui-qt-5" ... which would mean "I normally want GUI features built, but not if it means pulling in qt5." For the req-alt (required alternative) flags, the user could set ONLY ONE at a specific choice-level (here, the gtk/qt choice level, and the gtk2/3 and qt4/5 choice-levels), with EAPI enforcing it. Then an ebuild would set the /deepest/ level it needed, and possibly a choice variable, something like (UH=USE-Hierarchy)... UH_MAX_LVL="gui-gtk-2,gui-gtk3 level-use-x,level-use-y" UH_CHOICE="" ... and the EAPI, possibly plus an eclass to allow expanding the sets, would then have logic similar to the following table for the gtk set (EAPI support needed as traditional USE flags default off if not set on, and three-way flags, on/off/unset, would be necessary here): ! = unset - = set -flag + = set flag (+flag) x = flag setting doesn't matter gui gui-gtk gui-gtk-2 gui-gtk-3 note/build ---------------------------------------------------------------- ! ! ! ! all unset, build none ! ! ! - unset/negative, build none ! ! ! + only gtk3 set, build gtk3 ! ! - ! unset/negative, build none ! ! - - unset/negative, build none ! ! - + build gtk3 ! ! + ! build gtk2 ! ! + - build gtk2 ! ! + + build both gtk2/3 [1] ! - x x -gui-gtk, build none [2] ! + ! ! ebuild-pref [3] ! + ! - build gtk2 ! + ! + build gtk3 ! + - ! build gtk3 ! + - - build none [4] ! + - + build gtk3 - x x x -gui, build none [2] + ! ! ! +gui, !others, eb-pref [3] + - x x -gui-gtk, build none [5] + + ! ! ebuild-pref [3] + + ! - build gtk2 + + ! + build gtk3 + + - ! build gtk3 + + - - build none [4] + + - + build gtk3 + + + ! build gtk2 + + + - build gtk2 + + + + build both gtk2/3 -------------------------------------------------------------- [1] Since UH_CHOICE was unset or null in the ebuild, both can be built. If it was set, the user/profile settings for choice-alt-gtk* would be evaluated to decide. [2] With the higher level flag set negative, the lower level flags don't matter as the user/profile said they don't want it with the higher level flag. [3] With the higher level set positive and lower levels unset, user/ profile doesn't care at the lower level, so build both or maintainer pref, if ebuild didn't set UH_CHOICE. If ebuild set UH_CHOICE, only one can be built, evaluate the user/profile value for choice-alt-gtk* to decide. [4] User/profile says they want gtk GUI, but don't want either gtk2 or gtk3. What? But the effect is gui-gtk but not if it's either of the possible gtk options, so don't build them. [5] User/profile says gui, but not when it's gtk, so gtk builds being the only gui possible, don't build them. Obviously if qt4/5 are also options, there'd be a similar matrix for them, plus another level controlling the qt/gtk choice. Fed the correct UH_* settings and deciding based on the user/profile settings, the EAPI or eclass function would return a list of options to build from among those indicated by the UH_* vars, with the added possibility of ebuild-preference, which would let the ebuild choose its preferred, or it could build both/all. At the gtk-only or qt-only levels, there'd be only the version choices. Similarly if only one version of each was supported, as it'd then be a qt/ gtk choice. But if gtk2/3 and qt4/5 are all supported, there'd have to be a way to return "ebuild-choice of gtk, not qt, please", or conversely, "ebuild choice of qt, not gtk, please", as well as "ebuild-choice of whatever". To complete the set, "ebuild choice of gtk/qt, but if it's gtk, I want this version" (and similar for qt) might be worthwhile, but I'm not sure whether there'd be a real use-case for that or not. If not, perhaps it could simply spit an error, to avoid having to implement that bit of the choice matrix. Clearly this would be rather complex to setup, but the idea would be to code it once in the EAPI possibly plus the eclass, after which ebuilds would simply set the vars according to what choices they had, call the function to return the build choice, and let the return tell them what to build. Thus, it would be once per PM, plus possibly the expansion in the eclass, with little code in the ebuilds themselves. So complex, yes, but if it can solve the problem so we don't keep coming back to it... Like I said, I'm not sure it's practical, but even if not, I believe there's value in simply having it on the table for discussion, if for nothing else than for actually going there, as an example of the potential complexity of trying to take it too far. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
