1 |
On 06/03/2016 07:35 AM, Ian Stakenvicius wrote: |
2 |
> On 02/06/16 09:48 PM, Nick Vinson wrote: |
3 |
>> On 06/02/2016 08:08 AM, Raymond Jennings wrote: |
4 |
>>> use case: Telling a package to build a gui without deciding which one |
5 |
>>> to build. Also helps in cases where you have package A that can only |
6 |
>>> build a qt gui, and package B that can build both qt and gtk, and |
7 |
>>> package C that can build gtk only. You want to have a gui for all |
8 |
>>> three, but you don't want to hav epackage B build both guis and at the |
9 |
>>> same time while you may prefer qt, you don't want to leave package C |
10 |
>>> without a gui. |
11 |
>> |
12 |
>> How do you decide which one package B builds in such a case? |
13 |
>> |
14 |
>> Honestly, I don't think this is a good idea. The rationale and |
15 |
>> suggested implementation just don't bring enough benefit in my opinion. |
16 |
>> Often times it's hard enough to research a reported issue with the |
17 |
>> current implementation. Having a flag like 'gui' whose behavior |
18 |
>> (potentially) changes based on what profile is being used makes things |
19 |
>> considerably harder. It would no longer be a simple matter of matching |
20 |
>> versions and USE flags, the package maintainer would also need to setup |
21 |
>> an equivalent system with the same profile or research what the 'gui' |
22 |
>> flag with profile 'x' does and setup an equivalent USE flag set. |
23 |
> |
24 |
> |
25 |
> OK this makes absolutely no sense. |
26 |
> |
27 |
> USE=gui is about building the graphical user interface that an |
28 |
> application offers, when it is optional. That's it. What |
29 |
> dependencies that means and so on have nothing to do with the flag. |
30 |
|
31 |
Which only works with packages that provide support for a single GUI |
32 |
implementation. In cases where there's more than 1 option, you have to |
33 |
either introduce RESTRICTED_USE as Patrick alluded to, or decide a |
34 |
pecking order (or decide who gets to decide the pecking order). |
35 |
|
36 |
and in that case, it *does* matter what dependencies the gui flag will |
37 |
pull in. Even if the user doesn't care, there's no reason for it to |
38 |
pull in version A when version B is also supported by the package and |
39 |
every other package with GUI support is using version B. |
40 |
|
41 |
> It's the same as USE="server" to build the server daemon for an app |
42 |
> that provides both client and server. |
43 |
|
44 |
Maybe if IPX was still popular and I had to be concerned about whether |
45 |
"server" would favor a TCP/IP server or an IPX one, but that's not the |
46 |
case, so I don't see the two being equivalent here. |
47 |
|
48 |
In fact, I see this flag more like the 'dedicated' USE flag (which in my |
49 |
opinion, causes more problems than it solves). |
50 |
|
51 |
> |
52 |
> You get that use flags are not supposed to represent dependencies |
53 |
> right, but features of the package?? If you're only able to debug a |
54 |
> build of your package because the flag is called gtk instead of gui, |
55 |
> well... |
56 |
|
57 |
I'm well aware how use flags are supposed to work, thank you. Also had |
58 |
you actually read what I had wrote and the context surrounding it, you |
59 |
probably wouldn't have made such an asinine remark. |
60 |
|
61 |
> |
62 |
> |
63 |
>> |
64 |
>> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly |
65 |
>> do the same thing. The only thing they don't do (as I understand the |
66 |
>> profiles) is enable GUI support for packages that don't support the |
67 |
>> preferred libraries. Is that really enough justification to implement |
68 |
>> this flag? |
69 |
> |
70 |
> Yes. |
71 |
> |
72 |
> More specifically, the cleanup of all of those other uses of flags |
73 |
> that are there just to trigger a gui build instead of to indicate a |
74 |
> choice between options, is also enough justification. Think about a |
75 |
> wayland system -- there's lots of packages that IUSE="X" to build |
76 |
> their gui implementation. If someone wanting wayland set USE="-X" |
77 |
> then they don't get the gui app even if it'll work in wayland just fine. |
78 |
> |
79 |
> Yes, the USE=gui on this hypothetical app may well pull in Xorg libs, |
80 |
> but that's not a reason to keep the flag called "X", because again, |
81 |
> its about the feature of the package *not* the dependency. |
82 |
|
83 |
Sure it is. The feature is supporting X11 not Wayland or some |
84 |
hypothetical "omnigui". Do you really think upstream is going to care |
85 |
if their X11 app fails to work correct correctly in Wayland, but runs |
86 |
fine in a native X11 setup? |
87 |
|
88 |
I tunnel X11 over ssh all the time, do you really think it makes more |
89 |
since for me to have to set the 'gui' flag to do this instead of the X flag? |
90 |
|
91 |
Yes, I agree that the 'X' flag should control a feature. For most |
92 |
packages, that feature is integrating with an X11 environment (i.e. |
93 |
providing X11 bindings) and for most packages the X11 feature introduces |
94 |
dependencies on the X11 libraries. The gui flag won't change that. |
95 |
|
96 |
Nor does it make sense to rename 'X' to gui just because a Wayland user |
97 |
misconfigured his system. In your scenario, the user requested that the |
98 |
packages not be built with the X feature, so that's what they got. The |
99 |
fact that it would have otherwise worked with Wayland is immaterial. |
100 |
|
101 |
> |
102 |
> |
103 |
>> |
104 |
>> As a maintainer I'd ask that, at the very least, a more compelling |
105 |
>> reason than "it's too annoying to update package.use" is given. I find |
106 |
>> the argument against putting all the flags in global a valid but weak as |
107 |
>> there are already mitigations for that scenario. Perhaps I'm missing |
108 |
>> something, but I'm not convinced this will provide a significant enough |
109 |
>> benefit to the average Gentoo user to offset the increased |
110 |
>> troubleshooting demand it'll put on Gentoo's developers, maintainers, |
111 |
>> and proxy-maintainers. |
112 |
> |
113 |
> |
114 |
> Again, you will very much need to elaborate on what these increased |
115 |
> troubleshooting demands are. If anything, I see this flag, which will |
116 |
> allow the various tooklit flags to just mean a choice between |
117 |
> toolkits, to make things *easier* for troubleshooting, not harder. |
118 |
|
119 |
Some of the proposals on how to handle the case where a package supports |
120 |
more than 1 implementation (e.g. supports qt and gtk), lead me to think |
121 |
that the gui flag would inadvertently mask how a package was actually |
122 |
built and configured. In such a case, troubleshooting is potentially harder. |
123 |
|
124 |
If that can't (or won't) happen, you can disregard that paragraph. |
125 |
> |
126 |
> |
127 |
> |