1 |
On 06/02/2016 08:08 AM, Raymond Jennings wrote: |
2 |
> use case: Telling a package to build a gui without deciding which one |
3 |
> to build. Also helps in cases where you have package A that can only |
4 |
> build a qt gui, and package B that can build both qt and gtk, and |
5 |
> package C that can build gtk only. You want to have a gui for all |
6 |
> three, but you don't want to hav epackage B build both guis and at the |
7 |
> same time while you may prefer qt, you don't want to leave package C |
8 |
> without a gui. |
9 |
|
10 |
How do you decide which one package B builds in such a case? |
11 |
|
12 |
Honestly, I don't think this is a good idea. The rationale and |
13 |
suggested implementation just don't bring enough benefit in my opinion. |
14 |
Often times it's hard enough to research a reported issue with the |
15 |
current implementation. Having a flag like 'gui' whose behavior |
16 |
(potentially) changes based on what profile is being used makes things |
17 |
considerably harder. It would no longer be a simple matter of matching |
18 |
versions and USE flags, the package maintainer would also need to setup |
19 |
an equivalent system with the same profile or research what the 'gui' |
20 |
flag with profile 'x' does and setup an equivalent USE flag set. |
21 |
|
22 |
Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly |
23 |
do the same thing. The only thing they don't do (as I understand the |
24 |
profiles) is enable GUI support for packages that don't support the |
25 |
preferred libraries. Is that really enough justification to implement |
26 |
this flag? |
27 |
|
28 |
As a maintainer I'd ask that, at the very least, a more compelling |
29 |
reason than "it's too annoying to update package.use" is given. I find |
30 |
the argument against putting all the flags in global a valid but weak as |
31 |
there are already mitigations for that scenario. Perhaps I'm missing |
32 |
something, but I'm not convinced this will provide a significant enough |
33 |
benefit to the average Gentoo user to offset the increased |
34 |
troubleshooting demand it'll put on Gentoo's developers, maintainers, |
35 |
and proxy-maintainers. |
36 |
|
37 |
Thanks, |
38 |
Nicholas Vinson |
39 |
|
40 |
P.S. I'd also like to add that I do spend a considerable amount of time |
41 |
in #gentoo and I don't recall seeing this problem come up that much. |
42 |
The closest I've seen was a user asking where /usr/bin/VirtualBox was |
43 |
(as it only gets installed when the proper qt USE flag is set), but |
44 |
based on personal experience that happens maybe 1 or 2 every 3 - 4 |
45 |
months (if that often). |
46 |
|
47 |
> |
48 |
> On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius <axs@g.o |
49 |
> <mailto:axs@g.o>> wrote: |
50 |
> |
51 |
> On 01/06/16 10:13 PM, waltdnes@××××××××.org |
52 |
> <mailto:waltdnes@××××××××.org> wrote: |
53 |
> > On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote |
54 |
> > |
55 |
> >> waltdnes@××××××××.org <mailto:waltdnes@××××××××.org> wrote: |
56 |
> >> |
57 |
> >>> I see this as at least a redundancy, if not a problem. First, let's |
58 |
> >>> look at the general case. An optional "UI" (User Interface) is also |
59 |
> >>> selected... |
60 |
> >>> * via the "tools" useflag 78 times in use.local.desc |
61 |
> >>> * via the "ncurses" useflag 10 times in use.local.desc. |
62 |
> >>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why |
63 |
> >>> does "ncurses" show up in use.local.desc ???) |
64 |
> >>> |
65 |
> >>> There is no need for an additional "TUI" (Text User Interface) use flag |
66 |
> >>> for these cases. "tools" and/or "ncurses" tells you enough. Similarly, |
67 |
> >>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever. The only |
68 |
> >>> thing they have in common is a hard-coded dependancy on graphics libs. |
69 |
> >>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever. |
70 |
> >>> Using any of them tells you enough. What do we accomplish by requiring |
71 |
> >>> one more USE flag? This will also make dependancy resolution of ebuilds |
72 |
> >>> more complex, i.e. slower. Why? |
73 |
> >> |
74 |
> >> Simple regular users don't want to be concerned with choice of toolkit |
75 |
> >> for every single package, as long as a GUI is provided. |
76 |
> > |
77 |
> > Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in |
78 |
> > make.conf. This will *FORCE* a gui where applicable. |
79 |
> > |
80 |
> |
81 |
> |
82 |
> The whole point of USE=gui is to get away from needing to do that. |
83 |
> Those flags should be used to choose -which- gui toolkit users want |
84 |
> when one is available, not to choose IF a gui should be built or not. |
85 |
> Take my example into account, i don't want anything qt based if I can |
86 |
> avoid it, but i definitely want wpa-gui. Right now I only get wpa-gui |
87 |
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant. I'm |
88 |
> not going to set that globally though because I don't want to choose |
89 |
> qt4 based front-ends for anything else, and having to guess for every |
90 |
> random package when i don't care so that I can set a package.use entry |
91 |
> for it is annoying. |
92 |
> |
93 |
> |
94 |
> >> Furthermore, this matches the recommended USE flag design where the |
95 |
> >> more important flags are provided as feature flags, while specific |
96 |
> >> dependency choice flags are minor. |
97 |
> > |
98 |
> > This is going to require *THREE* levels of flags, with the first one |
99 |
> > being totally unnecessary... |
100 |
> > |
101 |
> > Level 1) GUI |
102 |
> > |
103 |
> > Level 2) X or xorg or Wayland or Mir |
104 |
> > |
105 |
> > Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk |
106 |
> |
107 |
> |
108 |
> 1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its |
109 |
> needed. |
110 |
> |
111 |
> 2 - If X or Wayland or Mir support is available in a package, then yes |
112 |
> -- also i don't see a way that we don't need these. |
113 |
> |
114 |
> 3 - toolkit selection choices when a package supports multiple (but |
115 |
> only chooses one) is also a yes. AND, because we're not tying any-gui |
116 |
> to one of these flags it means that users are free to set just the one |
117 |
> variant that they prefer, globally, instead of having to mess about |
118 |
> per-package. It also means we can get rid of any or all of these |
119 |
> particular flags from profiles (except for 'gnome' or 'plasma' or the |
120 |
> desktop-variant-specific ones). |
121 |
> |
122 |
> The point here is that if there's an app (say, wpa_supplicant as |
123 |
> mentioned before) that provides a gui tool but no options as to what |
124 |
> that tool needs in terms of toolkit etc, we can -just- have USE=gui |
125 |
> control whether or not it's built. It'll pull in qt because qt is |
126 |
> what it needs, and if someone is dead set against having qt in their |
127 |
> system then they'll know from the dependency tree. There's no need to |
128 |
> peg the individual toolkit to packages like this just to enable a gui. |
129 |
> |
130 |
> |
131 |
> > |
132 |
> > Let me re-phrase my question... is there *ANY* set of circumstances |
133 |
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag |
134 |
> > can be set for a package *WITHOUT* requiring a gui? I can see any of X |
135 |
> > or xorg or Wayland or Mir being a requirement for any of |
136 |
> > qt4/qt5/gtk2/gtk3/fltk. But any of the Level 2 or Level 3 flags *FORCES* |
137 |
> > a GUI of one sort or another. |
138 |
> |
139 |
> |
140 |
> Likely there is but I'd need to search. Extending libraries mostly -- |
141 |
> cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ... |
142 |
> |
143 |
> |
144 |
> |
145 |
> |
146 |
> |