Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: mgorny@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493)
Date: Wed, 12 Feb 2014 09:14:42
Message-Id: 20140212101426.383e46bc@TOMWIJ-GENTOO
In Reply to: Re: [gentoo-dev] RFC: GTK USE flag situation (gtk, gtk2, gtk3; relevant to bug #420493) by "Michał Górny"
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

Attachments

File name MIME type
signature.asc application/pgp-signature