Gentoo Archives: gentoo-dev

From: Mart Raudsepp <leio@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Choosing GUI toolkits from multiple choices
Date: Sun, 05 Jun 2016 03:08:56
1 Ühel kenal päeval, R, 03.06.2016 kell 22:40, kirjutas Daniel Campbell:
2 > You touched on the part that I'm most concerned about: choosing. If
3 > the
4 > 'GUI' USE_EXPAND gets in, do we maintainers check that variable and
5 > if
6 > there's no preference just build whatever? Will we not be expected to
7 > emit an ewarn or something similar to clarify *why* the package is
8 > being
9 > built a certain way? Granted, if a user has a problem and reports a
10 > bug,
11 > their make.conf's GUI variable should be present in emerge -v output,
12 > easily explaining the issue.
14 Said 'GUI' USE_EXPAND is outside the intended scope of the USE=gui
15 thread, but anticipating discussion will happen regardless now, I've
16 cut the thread and named it something else.
17 Many discussions have happened on IRC on this as well, which is where
18 Daniel got this from.
21 I think it's actually a rather corner-case to have an optional GUI, and
22 then that GUI being buildable against a selection of toolkits. Arguably
23 in some of those cases it might be more ideal to have the GUI parts in
24 a separate package too, but usually upstream sources aren't so
25 accommodating to our source-based case (while binary distributions
26 split it up into multiple binary packages, built from one source in one
27 go).
28 In most cases when there's a choice, a GUI imho isn't usually optional.
29 You choose e.g qt4 or qt5, or gtk3 or qt5 and having both shipped is
30 not so common from the same package. Transmission is an example where
31 it is, because they have a multiple frontend system (arguably it would
32 be neat to have these in separate transmission-qt, transmission-gtk and
33 so on packages), and one of these can be a web service UI instead of a
34 dedicated graphics toolkit.
36 USE=gui would replace a ton of USE=gtk's at least, where it's mostly
37 about simple extra GUI tools added with a gtk2 dep, but I've seen it in
38 other toolkit cases too, but I don't know how common it is there.
39 Ideally USE=gui can be agreed upon while ignoring the corner-case of
40 multiple choices; in some of these cases it might make sense to ignore
41 USE=gui at the start, until the multiple choice case gets some
42 resolution though, e.g emacs and perhaps transmission could just keep
43 the current way until we agree how to express multiple choice cases
44 universally.
46 I drafted that mentioned USE_EXPAND idea as a means to get some 'design
47 from the scratch' discussion going and flesh out this way of
48 potentially doing it (such a USE_EXPAND was idly mentioned at start by
49 others as something that was deemed too crazy, but I didn't find any
50 references). It is currently still as a draft over at
51 -  but I didn't want the original
52 USE=gui thread to discuss this, as it's a separate and much more
53 complex matter really, and would work in tandem with USE=gui when
54 appropriate.
56 > It's the implementation that gets me here, not the idea. The idea
57 > could
58 > be neat and make Gentoo management easier at the expense of some
59 > (hopefully) minor ebuild bloat. Another issue that hasn't been
60 > covered
61 > well yet is how are we going to select DEPENDs? I was told DEPEND
62 > doesn't support exactly-one-of, and we don't want extraneous
63 > dependencies.
65 The part of it being not clear (due to the intentional lack of
66 REQUIRED_USE usage in that design) what is getting built is probably
67 the main drawback of that drafted idea, and some QA members tell me
68 this would be outright vetoed as a QA violation.
70 This uncertainty also echoes in the need for these complex DEPEND atoms
71 as well then, based on maintainer chosen preference, combined with user
72 set flags.
74 So it isn't ideal at all indeed, and we'd need to really do the
75 suggested EAPI/package manager improvements first, to express this
76 maintainer order of preference to the user and filter the flags somehow
77 to what will actually be chosen then before the DEPEND atoms get
78 processed, which would make the *DEPENDs feasible, as you could
79 simplify the conditionals, because the unused (but set by user) USE
80 flags are already filtered out then (or one added when user didn't have
81 any, and one would be chosen by default).
83 I ruled out REQUIRED_USE because I don't like it at all when it is used
84 together with common global USE flags, as opposed to just some local
85 flags. In my opinion it tends to results in users disabling or enabling
86 something globally, instead of locally for the package in question. And
87 with that having made the choice unknowingly for a ton of future
88 packages to be installed as well. pkg_pretend is a bit better, because
89 you can customize the error message to be readable, but it's still
90 something that takes away my choice of not having to care.. just give
91 me a GUI, preferably a gtk3 one, ok? thx.
93 > Transmission is a good example: supports gtk3, qt4, qt5. Let's say
94 > the
95 > maintainer prefers the qt5 version. Would we do this?:
97 > DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
98 > gui_gtk3? ( x11-libs/gtk+:3 )"
100 > or this?:
102 > DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"
104 > (snipping because I don't feel like writing it all out)
106 Transmissions is a good example indeed, but not in the way you describe
107 here, because transmission can be built with gtk and qt in parallel. So
108 it's a good example of what a hypothetical EAPI-next markup for
109 describing this order of choices would have to support. qt4 or qt5 or
110 neither is one choice. gtk2 or gtk3 or neither another. And none of
111 them have to be there, so if USE=-gui, GUI="..." is ignored, but with
112 USE=gui and GUI="<empty>" a qt5 choice would be made.
113 I wonder if the same syntax as REQUIRED_USE can be used for expressing
114 this, sans order of priority (unless it can be implicit from the order
115 of things listed).
117 If we had some way to express this, similar to REQUIRED_USE, that part
118 could take care of simplifying the DEPEND to
119 "gui? (
120  gui_qt5? ( dev-qt/qtgui:5 )
121  gui_qt4? ( dev-qt/qtgui:4 )
122  gui_gtk3? ( x11-libs/gtk+:3 )
123  gui_gtk2? ( x11-libs/gtk+:2 ) )"
124 if it would override the flags to what will be chosen for us already at
125 this point via some markup like
126 GUI_PREFS="gui? ( || ( ?? ( gui_qt5 gui_qt4 )  ?? ( gui_gtk3 gui_gtk2 )
127 ) )"
128 if we can default to the first of each branch of choice, or something
129 more complex to sequence these choices.
131 This could also probably be achieved one way or another via an eclass
132 (or maybe not - the rules of global variables like *DEPEND are rather
133 strict and I'm not sure you can influence them sufficiently via an
134 eclass), but that doesn't solve the issues of package manager not
135 really knowing what happened (apparently bad for binary packages), and
136 the user not knowing what's going on without reading the ebuild.
138 Brainstorming welcome on this, but a medium like IRC might be more
139 constructive at this point for that purpose.
142 Mart


Subject Author
Re: [gentoo-dev] Choosing GUI toolkits from multiple choices Mart Raudsepp <leio@g.o>