Re: [gentoo-dev] [RFC] Global USE=gui

[Michał Górny]

On Mon, 6 Jun 2016 10:53:54 -0400
Ian Stakenvicius <axs@g.o> 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/>