On Mon, 6 Jun 2016 10:53:54 -0400 Ian Stakenvicius <[email protected]> wrote:
> On 04/06/16 01:40 AM, Daniel Campbell wrote: > > 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. > > > A pkg_pretend() message would certainly make sense and IMO be a good > idea, but again this isn't any different than the situation as it > stands now WITHOUT a USE=gui. Regardless I don't see this as a > blocker to the idea. Nope, it won't. It will only make things slower, more clumsy and provide no real benefit. pkg_pretend() should be reserved for checks really needed to build packages and not abused to do some early output. > > 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. > > > ...you lost me on this one... You mean use-flag based operators to > select atoms in (R)DEPEND ? Yeah it doesn't but this isn't an issue > either. See below: > > > > 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) > > > Putting aside what seems to be a USE_EXPAND, for now, since as far as > I know that idea was squashed the day it was introduced on irc... > > OK, maintainer prefers the qt5 version as per your assumption, and > because I haven't looked, we'll assume that transmission's gui is > optional. RDEPEND would most likely be: > > RDEPEND="... > gui? ( > gtk3? ( x11-libs/gtk+:3 ) > !gtk3? ( > qt4? ( dev-qt/qtcore:4 ) > !qt4? ( dev-qt/qtcore:5 ) > ) > )" > > Note that the -default- doesn't need its own flag, since having qt5 > support be wrapped by a qt5 flag doesn't add anything. Note also that > the deps as they stand now should probably be almost identical: > > RDEPEND="... > qt5? ( dev-qt/qtcore:5 ) > !qt5? ( > gtk3? ( x11-libs/gtk+:3 ) > !gtk3? ( > qt4? ( dev-qt/qtcore:4 ) > ) > )" > > This -can- be simplified using a REQUIRED_USE to force just-one-of > gtk3,qt4,qt5 , but you can technically do the same with USE=gui too -- > all you'd need to do is add dependencies for the no-specific-flag case. > > RDEPEND="... > qt5? ( dev-qt/qtcore:5 ) > qt4? ( dev-qt/qtcore:4 ) > gtk3? ( x11-libs/gtk+:3 ) > gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )" > > And of course you could also force one of qt5/qt4/gtk3 to be enabled > via REQUIRED_USE if USE=gui is set, as well. > > AND, finally, as was alluded to in the original post, it could well be > that we don't want to bother with putting USE=gui onto packages such > as transmission, because when there's multiple toolkits to choose from > like this it just doesn't make sense. That's not really for me to > decide. What I want it for most is to clean up the packages that are > using one of these toolkit flags to just enable the gui of the one > toolkit it supports, as there's still plenty of those. Best practices > for multi-toolkit (including the possibility of no-change) can be > decided upon later. > > > Back to the code -- are there problems with any or all of these > options? Yes; the primary one being that flag state changes for the > toolkit(s) that -arent- actually being used will trigger pointless > rebuilds. However, this isn't actually different from anything that, > say, has both qt4 and qt5 in IUSE. So I don't see it as being a > show-stopper either. It would be nice to figure out how to avoid said > useless-rebuilds but that imo leads into PMS/EAPI7 territory. So many weird ideas... while the simplest one is a proper REQUIRED_USE with gui being the control flag, and IUSE defaults to select the preferred toolkit. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpm8MO4cPF0C.pgp
Description: OpenPGP digital signature
