1 |
On Wed, 12 Feb 2014 09:05:59 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Dnia 2014-02-12, o godz. 00:39:14 |
5 |
> Alex Alexander <wired@g.o> napisał(a): |
6 |
> |
7 |
> > Some developers choose to follow the Gnome team's highlights, while |
8 |
> > others choose to go their own way. The QA team would like to |
9 |
> > establish a guideline that solves this problem in the best way |
10 |
> > possible. |
11 |
> |
12 |
> First of all, I think that the policy on a flag related to GTK+ should |
13 |
> be set by the GTK+ maintainer, that is the GNOME team, and not |
14 |
> directly by QA. |
15 |
|
16 |
The GNOME team has already made a recommendation on this; and feel free |
17 |
to correct me, but I think they internally regard it as a policy the |
18 |
GNOME team itself has to apply. |
19 |
|
20 |
> If people dislike the policy set by GNOME, they can appeal to QA, |
21 |
> sure. |
22 |
|
23 |
This is what indirectly happens here; hasufell brought this up to us, |
24 |
as people are closing bugs blocking below tracker as RESOLVED WONTFIX: |
25 |
|
26 |
https://bugs.gentoo.org/show_bug.cgi?id=420493 |
27 |
|
28 |
An overview of the bugs blocking this tracker: |
29 |
|
30 |
https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493 |
31 |
|
32 |
> But IMO afterwards QA should either give their blessing to the |
33 |
> current GNOME policy or tell GNOME to change the policy, not step in |
34 |
> front of them with a 'higher instance override'. |
35 |
|
36 |
We've brought leio early into the discussion during the QA team |
37 |
meeting; as it currently stands, I think this is still a recommendation |
38 |
which makes it easier for people to object it. |
39 |
|
40 |
We've planned to bring this out to the mailing list (as wired did), as |
41 |
well as clarify the objections to it; in an attempt to listen and then |
42 |
discuss and work with the GNOME team on making this work for everyone. |
43 |
|
44 |
> > During our discussion, it was pointed out that keeping a generic |
45 |
> > USE="gtk" is sub-optimal. The non-straightforward nature of new |
46 |
> > toolkit versions makes transitioning from one to the other a slow, |
47 |
> > tedius process and we think that a non-versioned USE flag makes |
48 |
> > things even worse. |
49 |
> |
50 |
> How does the flag exactly do that? I don't seem to get the point |
51 |
> in that paragraph. |
52 |
|
53 |
What do we think the flag does? There are multiple ways to interpret |
54 |
"gtk - Add support for x11-libs/gtk+ (The GIMP Toolkit)" if you want |
55 |
to; and depending on that, there are underlying difficulties that pop |
56 |
up. Does it cover one slot or all slots? If it covers one slot, should |
57 |
it be named after that slot instead? If it covers multiple slots, |
58 |
quoting leio: Why don't we just rename it to USE="gui"? |
59 |
|
60 |
Other people more acknowledged with that can probably explain it more |
61 |
well, but realistically the USE flag description should explain this |
62 |
more clear such that we don't need to explain it; now, consider this: |
63 |
|
64 |
Why is there no USE="qt" for Qt? Why do we not need it there? |
65 |
|
66 |
> > To achieve this, version 3 of gtk should always be enabled by |
67 |
> > USE="gtk3". At some point in the future, when gtk2 consumers reach |
68 |
> > zero, we will retire "gtk" for good. Then, if some day gtk4 comes |
69 |
> > around, we will be able to introduce support for it in the tree by |
70 |
> > simply adding USE="gtk4", without having to re-structure half the |
71 |
> > tree. |
72 |
> |
73 |
> This goes exactly against the policy that is being established e.g. |
74 |
> for USE=ssl. If QA is really supposed to set a policy here, it should |
75 |
> set a generic policy for all those cases. |
76 |
> |
77 |
> USE flags should represent *features*, not tools used to implement |
78 |
> them. If users want SSL support in an application, they want to set |
79 |
> USE=ssl and stop caring. Not look through all the USE flags in case |
80 |
> application used USE=openssl, USE=gnutls, USE=polarssl etc. for it. |
81 |
|
82 |
Exactly, I think this backs up the USE="gui" idea above. |
83 |
|
84 |
[TL;DR: Skip the next two paragraphs, we're agreeing on that; I just |
85 |
left it in for if anyone wants to read it for furtherer understanding.] |
86 |
|
87 |
As for the versioned USE="gtk3", ...; I'm wondering how the user would |
88 |
then specify what to build for, or even worse: If a package depends on |
89 |
gtk+ without a SLOT and was build against gtk3, then the user wants to |
90 |
support gtk4 as well but hold on to gtk3 until all his packages work |
91 |
with gtk4, how would you reflect that in the ebuild? |
92 |
|
93 |
I see USE="gtk" --> USE="gui" as a good idea; however, for a reason |
94 |
like the above where control as to which GTK version is supported |
95 |
(benefits changed USE flag rebuilds) is needed by the user are affected |
96 |
if we decide to do something about the versioned USE="gtk3", ... |
97 |
|
98 |
> Multiple USE flags make sense when there's support for multiple |
99 |
> toolkits that works and is maintained, and the user may reasonably |
100 |
> want to switch between them. But then, the extra USE flags for toolkit |
101 |
> switching should be introduced with keeping USE=ssl as the generic |
102 |
> on/off switch and the specific flags an optional implementation switch |
103 |
> for power users. |
104 |
> |
105 |
> In the end, GTK+ is much the same. You want GTK+ GUI, you enable |
106 |
> USE=gtk. You need specific switching between 2 and 3, assuming it is |
107 |
> *reasonable and well supported*, you can use extra USE=gtk2 or |
108 |
> USE=gtk3. |
109 |
|
110 |
Sorry; should have read further before writing my previous quote |
111 |
response, there's agreement here to a large extent as you can see by |
112 |
the previous two paragraphs. |
113 |
|
114 |
> This generally works, and causes issues mostly to complainers alike |
115 |
> 'I dislike this, I want to be able to easily mask it all'. I don't |
116 |
> think there's a point messing up the general case for the sake of |
117 |
> complainers that will either end up enabling USE=gtk3 anyway at some |
118 |
> point or end up without a GUI. |
119 |
> |
120 |
> That said, I'm all for killing most of USE=gtk, USE=wxwidgets, USE=qt* |
121 |
> occurrences with a generic USE=gui following the earlier principle. |
122 |
|
123 |
This last sentence (especially the * on qt) makes me wonder if we fully |
124 |
agree though; as put out in the two paragraphs I told you to skip, this |
125 |
takes a bit of control away from the user which some users might want. |
126 |
|
127 |
Also seems you are already aware of USE="gui" (or came up with it too). |
128 |
|
129 |
> If user installs an application and wants a GUI for it, shklee |
130 |
> shouldn't have to care whether it's GTK+, wxWidgets or Qt. Gentoo |
131 |
> should be a distribution friendly to all toolkits, people who collect |
132 |
> applications specific to a single toolkit belong in {,k,x}ubuntu. |
133 |
> Then, the special USE flags make sense for fine-picking one |
134 |
> of the toolkits when multiple are supported. |
135 |
|
136 |
Yes; in this context, users can mask what they want to avoid. |
137 |
|
138 |
-- |
139 |
With kind regards, |
140 |
|
141 |
Tom Wijsman (TomWij) |
142 |
Gentoo Developer |
143 |
|
144 |
E-mail address : TomWij@g.o |
145 |
GPG Public Key : 6D34E57D |
146 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |