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. |
13 |
|
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. |
19 |
|
20 |
|
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. |
35 |
|
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. |
45 |
|
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 |
http://piratepad.net/iwvgjB1P5d - 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. |
55 |
|
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. |
64 |
|
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. |
69 |
|
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. |
73 |
|
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). |
82 |
|
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. |
92 |
|
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?: |
96 |
> |
97 |
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 ) |
98 |
> gui_gtk3? ( x11-libs/gtk+:3 )" |
99 |
> |
100 |
> or this?: |
101 |
> |
102 |
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )" |
103 |
> |
104 |
> (snipping because I don't feel like writing it all out) |
105 |
|
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). |
116 |
|
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. |
130 |
|
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. |
137 |
|
138 |
Brainstorming welcome on this, but a medium like IRC might be more |
139 |
constructive at this point for that purpose. |
140 |
|
141 |
|
142 |
Mart |