On 06/03/2016 09:07 PM, Ian Stakenvicius wrote: > On 03/06/16 11:26 PM, Nick Vinson wrote: >> >> [ Snip! ] In cases where there's more than 1 option, you have to >> either introduce RESTRICTED_USE as Patrick alluded to, or decide a >> pecking order (or decide who gets to decide the pecking order). > > > Which dev's already need to do, without USE=gui -- this is not a > deviation from the status quo. > > >> >> and in that case, it *does* matter what dependencies the gui flag will >> pull in. Even if the user doesn't care, there's no reason for it to >> pull in version A when version B is also supported by the package and >> every other package with GUI support is using version B. >> > > And USE=gui is not going to eliminate said choices when there are > choices between toolkits for a package. > >> >> Some of the proposals on how to handle the case where a package supports >> more than 1 implementation (e.g. supports qt and gtk), lead me to think >> that the gui flag would inadvertently mask how a package was actually >> built and configured. In such a case, troubleshooting is potentially harder. >> >> If that can't (or won't) happen, you can disregard that paragraph. > > > That can't or won't happen. NOTHING about the USE=gui proposal turns > deterministic things into automagic things. It's just about > restructuring the determinism. > > Now, as is the case already for packages like this without a > REQUIRED_USE line, if a package supports just one of both gtk and qt5, > and both flags are enabled, then the package maintainer needs to > determine which one takes precedence and the state of the other will > be ignored. This isn't ideal since it can amount to useless rebuilds, > but it isn't automagic either. > > > You touched on the part that I'm most concerned about: choosing. If the 'GUI' USE_EXPAND gets in, do we maintainers check that variable and if there's no preference just build whatever? Will we not be expected to emit an ewarn or something similar to clarify *why* the package is being built a certain way? Granted, if a user has a problem and reports a bug, their make.conf's GUI variable should be present in emerge -v output, easily explaining the issue.
It's the implementation that gets me here, not the idea. The idea could be neat and make Gentoo management easier at the expense of some (hopefully) minor ebuild bloat. Another issue that hasn't been covered well yet is how are we going to select DEPENDs? I was told DEPEND doesn't support exactly-one-of, and we don't want extraneous dependencies. Transmission is a good example: supports gtk3, qt4, qt5. Let's say the maintainer prefers the qt5 version. Would we do this?: DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 ) gui_gtk3? ( x11-libs/gtk+:3 )" or this?: DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )" (snipping because I don't feel like writing it all out) Thing is, what would an empty GUI do? Would we fall back to IUSE? What if all three are present in GUI? Someone (I forget who) had an idea to specify priority in the GUI variable. How will that be supported in ebuilds? With a gui.eclass? I'm almost to the point with this discussion that we just need a few blatant, no-op test ebuilds and a portage patch or something to demonstrate how it would be handled. Code talks a lot better than we do. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
