1 |
On 04/06/16 01:40 AM, Daniel Campbell wrote: |
2 |
> On 06/03/2016 09:07 PM, Ian Stakenvicius wrote: |
3 |
>> On 03/06/16 11:26 PM, Nick Vinson wrote: |
4 |
>>> |
5 |
>>> [ Snip! ] In cases where there's more than 1 option, you have to |
6 |
>>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a |
7 |
>>> pecking order (or decide who gets to decide the pecking order). |
8 |
>> |
9 |
>> |
10 |
>> Which dev's already need to do, without USE=gui -- this is not a |
11 |
>> deviation from the status quo. |
12 |
>> |
13 |
>> |
14 |
>>> |
15 |
>>> and in that case, it *does* matter what dependencies the gui flag will |
16 |
>>> pull in. Even if the user doesn't care, there's no reason for it to |
17 |
>>> pull in version A when version B is also supported by the package and |
18 |
>>> every other package with GUI support is using version B. |
19 |
>>> |
20 |
>> |
21 |
>> And USE=gui is not going to eliminate said choices when there are |
22 |
>> choices between toolkits for a package. |
23 |
>> |
24 |
>>> |
25 |
>>> Some of the proposals on how to handle the case where a package supports |
26 |
>>> more than 1 implementation (e.g. supports qt and gtk), lead me to think |
27 |
>>> that the gui flag would inadvertently mask how a package was actually |
28 |
>>> built and configured. In such a case, troubleshooting is potentially harder. |
29 |
>>> |
30 |
>>> If that can't (or won't) happen, you can disregard that paragraph. |
31 |
>> |
32 |
>> |
33 |
>> That can't or won't happen. NOTHING about the USE=gui proposal turns |
34 |
>> deterministic things into automagic things. It's just about |
35 |
>> restructuring the determinism. |
36 |
>> |
37 |
>> Now, as is the case already for packages like this without a |
38 |
>> REQUIRED_USE line, if a package supports just one of both gtk and qt5, |
39 |
>> and both flags are enabled, then the package maintainer needs to |
40 |
>> determine which one takes precedence and the state of the other will |
41 |
>> be ignored. This isn't ideal since it can amount to useless rebuilds, |
42 |
>> but it isn't automagic either. |
43 |
>> |
44 |
>> |
45 |
>> |
46 |
> You touched on the part that I'm most concerned about: choosing. If the |
47 |
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and if |
48 |
> there's no preference just build whatever? Will we not be expected to |
49 |
> emit an ewarn or something similar to clarify *why* the package is being |
50 |
> built a certain way? Granted, if a user has a problem and reports a bug, |
51 |
> their make.conf's GUI variable should be present in emerge -v output, |
52 |
> easily explaining the issue. |
53 |
|
54 |
|
55 |
A pkg_pretend() message would certainly make sense and IMO be a good |
56 |
idea, but again this isn't any different than the situation as it |
57 |
stands now WITHOUT a USE=gui. Regardless I don't see this as a |
58 |
blocker to the idea. |
59 |
|
60 |
|
61 |
> |
62 |
> It's the implementation that gets me here, not the idea. The idea could |
63 |
> be neat and make Gentoo management easier at the expense of some |
64 |
> (hopefully) minor ebuild bloat. Another issue that hasn't been covered |
65 |
> well yet is how are we going to select DEPENDs? I was told DEPEND |
66 |
> doesn't support exactly-one-of, and we don't want extraneous dependencies. |
67 |
|
68 |
|
69 |
...you lost me on this one... You mean use-flag based operators to |
70 |
select atoms in (R)DEPEND ? Yeah it doesn't but this isn't an issue |
71 |
either. See below: |
72 |
|
73 |
|
74 |
> Transmission is a good example: supports gtk3, qt4, qt5. Let's say the |
75 |
> maintainer prefers the qt5 version. Would we do this?: |
76 |
> |
77 |
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 ) |
78 |
> gui_gtk3? ( x11-libs/gtk+:3 )" |
79 |
> |
80 |
> or this?: |
81 |
> |
82 |
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )" |
83 |
> |
84 |
> (snipping because I don't feel like writing it all out) |
85 |
|
86 |
|
87 |
Putting aside what seems to be a USE_EXPAND, for now, since as far as |
88 |
I know that idea was squashed the day it was introduced on irc... |
89 |
|
90 |
OK, maintainer prefers the qt5 version as per your assumption, and |
91 |
because I haven't looked, we'll assume that transmission's gui is |
92 |
optional. RDEPEND would most likely be: |
93 |
|
94 |
RDEPEND="... |
95 |
gui? ( |
96 |
gtk3? ( x11-libs/gtk+:3 ) |
97 |
!gtk3? ( |
98 |
qt4? ( dev-qt/qtcore:4 ) |
99 |
!qt4? ( dev-qt/qtcore:5 ) |
100 |
) |
101 |
)" |
102 |
|
103 |
Note that the -default- doesn't need its own flag, since having qt5 |
104 |
support be wrapped by a qt5 flag doesn't add anything. Note also that |
105 |
the deps as they stand now should probably be almost identical: |
106 |
|
107 |
RDEPEND="... |
108 |
qt5? ( dev-qt/qtcore:5 ) |
109 |
!qt5? ( |
110 |
gtk3? ( x11-libs/gtk+:3 ) |
111 |
!gtk3? ( |
112 |
qt4? ( dev-qt/qtcore:4 ) |
113 |
) |
114 |
)" |
115 |
|
116 |
This -can- be simplified using a REQUIRED_USE to force just-one-of |
117 |
gtk3,qt4,qt5 , but you can technically do the same with USE=gui too -- |
118 |
all you'd need to do is add dependencies for the no-specific-flag case. |
119 |
|
120 |
RDEPEND="... |
121 |
qt5? ( dev-qt/qtcore:5 ) |
122 |
qt4? ( dev-qt/qtcore:4 ) |
123 |
gtk3? ( x11-libs/gtk+:3 ) |
124 |
gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )" |
125 |
|
126 |
And of course you could also force one of qt5/qt4/gtk3 to be enabled |
127 |
via REQUIRED_USE if USE=gui is set, as well. |
128 |
|
129 |
AND, finally, as was alluded to in the original post, it could well be |
130 |
that we don't want to bother with putting USE=gui onto packages such |
131 |
as transmission, because when there's multiple toolkits to choose from |
132 |
like this it just doesn't make sense. That's not really for me to |
133 |
decide. What I want it for most is to clean up the packages that are |
134 |
using one of these toolkit flags to just enable the gui of the one |
135 |
toolkit it supports, as there's still plenty of those. Best practices |
136 |
for multi-toolkit (including the possibility of no-change) can be |
137 |
decided upon later. |
138 |
|
139 |
|
140 |
Back to the code -- are there problems with any or all of these |
141 |
options? Yes; the primary one being that flag state changes for the |
142 |
toolkit(s) that -arent- actually being used will trigger pointless |
143 |
rebuilds. However, this isn't actually different from anything that, |
144 |
say, has both qt4 and qt5 in IUSE. So I don't see it as being a |
145 |
show-stopper either. It would be nice to figure out how to avoid said |
146 |
useless-rebuilds but that imo leads into PMS/EAPI7 territory. |