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.
>
> 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.
signature.asc
Description: OpenPGP digital signature
