1 |
On 06/03/2016 09:07 PM, Ian Stakenvicius wrote: |
2 |
> On 03/06/16 11:26 PM, Nick Vinson wrote: |
3 |
>> |
4 |
>> [ Snip! ] In cases where there's more than 1 option, you have to |
5 |
>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a |
6 |
>> pecking order (or decide who gets to decide the pecking order). |
7 |
> |
8 |
> |
9 |
> Which dev's already need to do, without USE=gui -- this is not a |
10 |
> deviation from the status quo. |
11 |
> |
12 |
> |
13 |
>> |
14 |
>> and in that case, it *does* matter what dependencies the gui flag will |
15 |
>> pull in. Even if the user doesn't care, there's no reason for it to |
16 |
>> pull in version A when version B is also supported by the package and |
17 |
>> every other package with GUI support is using version B. |
18 |
>> |
19 |
> |
20 |
> And USE=gui is not going to eliminate said choices when there are |
21 |
> choices between toolkits for a package. |
22 |
> |
23 |
>> |
24 |
>> Some of the proposals on how to handle the case where a package supports |
25 |
>> more than 1 implementation (e.g. supports qt and gtk), lead me to think |
26 |
>> that the gui flag would inadvertently mask how a package was actually |
27 |
>> built and configured. In such a case, troubleshooting is potentially harder. |
28 |
>> |
29 |
>> If that can't (or won't) happen, you can disregard that paragraph. |
30 |
> |
31 |
> |
32 |
> That can't or won't happen. NOTHING about the USE=gui proposal turns |
33 |
> deterministic things into automagic things. It's just about |
34 |
> restructuring the determinism. |
35 |
> |
36 |
> Now, as is the case already for packages like this without a |
37 |
> REQUIRED_USE line, if a package supports just one of both gtk and qt5, |
38 |
> and both flags are enabled, then the package maintainer needs to |
39 |
> determine which one takes precedence and the state of the other will |
40 |
> be ignored. This isn't ideal since it can amount to useless rebuilds, |
41 |
> but it isn't automagic either. |
42 |
> |
43 |
> |
44 |
> |
45 |
You touched on the part that I'm most concerned about: choosing. If the |
46 |
'GUI' USE_EXPAND gets in, do we maintainers check that variable and if |
47 |
there's no preference just build whatever? Will we not be expected to |
48 |
emit an ewarn or something similar to clarify *why* the package is being |
49 |
built a certain way? Granted, if a user has a problem and reports a bug, |
50 |
their make.conf's GUI variable should be present in emerge -v output, |
51 |
easily explaining the issue. |
52 |
|
53 |
It's the implementation that gets me here, not the idea. The idea could |
54 |
be neat and make Gentoo management easier at the expense of some |
55 |
(hopefully) minor ebuild bloat. Another issue that hasn't been covered |
56 |
well yet is how are we going to select DEPENDs? I was told DEPEND |
57 |
doesn't support exactly-one-of, and we don't want extraneous dependencies. |
58 |
|
59 |
Transmission is a good example: supports gtk3, qt4, qt5. Let's say the |
60 |
maintainer prefers the qt5 version. Would we do this?: |
61 |
|
62 |
DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 ) |
63 |
gui_gtk3? ( x11-libs/gtk+:3 )" |
64 |
|
65 |
or this?: |
66 |
|
67 |
DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )" |
68 |
|
69 |
(snipping because I don't feel like writing it all out) |
70 |
|
71 |
Thing is, what would an empty GUI do? Would we fall back to IUSE? What |
72 |
if all three are present in GUI? Someone (I forget who) had an idea to |
73 |
specify priority in the GUI variable. How will that be supported in |
74 |
ebuilds? With a gui.eclass? |
75 |
|
76 |
I'm almost to the point with this discussion that we just need a few |
77 |
blatant, no-op test ebuilds and a portage patch or something to |
78 |
demonstrate how it would be handled. Code talks a lot better than we do. |
79 |
|
80 |
-- |
81 |
Daniel Campbell - Gentoo Developer |
82 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
83 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |