Gentoo Archives: gentoo-dev

From: Daniel Campbell <zlg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
Date: Fri, 27 May 2016 18:57:35
Message-Id: f03622c7-42be-ac1c-9166-49711bb2b952@gentoo.org
In Reply to: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation by Mart Raudsepp
1 On 05/27/2016 07:21 AM, Mart Raudsepp wrote:
2 > Hello,
3 >
4 > Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
5 > upstream, many applications still support only gtk2, have subtle issues
6 > with their gtk3 port, or support both, with some of our userbase
7 > clinging to gtk2 for dubious political or aesthetical reasons.
8 >
9 > For the latter cases, despite GNOME teams policy and strong preference
10 > on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
11 > working as good as gtk2), some cases exist where the maintainers want
12 > to provide such choice. In some cases it is understandable for a short
13 > while during transition, e.g firefox. In other cases, it is purely for
14 > the sake of providing the choice of working with a deprecated toolkit,
15 > apparently.
16 >
17 > My highly biased essay aside, we need to finally globally agree on what
18 > we do in this situation. If we allow this choice at all, only for
19 > special cases, or widespread. And if this choice is provided, how do we
20 > name the USE flag.
21 >
22 > Historically, for very good reasons in past and present GNOME team
23 > members opinion, USE=gtk has always meant to mean to provide support
24 > for gtk in general, not any particular version. This is opposite to
25 > what the Qt team has been doing.
26 > In our opinion, in a perfect world, only USE=gtk would exist, and no
27 > USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
28 > perfect world, we have made use of USE=gtk3 for providing gtk3 support
29 > from library packages to mean to build gtk3 support. Sadly that
30 > overloads USE=gtk in many cases to then mean to build gtk2 support.
31 > This would ideally not be needed, as the package would instead be
32 > slotted and parallel installable for gtk2 and gtk3, which should be
33 > theoretically possible in all cases, because gtk2 and gtk3 may not live
34 > in the same process, so not the same library either.
35 > Due to some packages needing too much manpower effort to do such a
36 > split, USE flags are used in such a case.
37 > Good examples of such slot splits existing are for example the
38 > libappindicator stack. This used to be the case with almost all GNOME
39 > libraries as well, but most of them only provide gtk3 now, as gtk2 is,
40 > well, dead.
41 > Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
42 > split up into separate SLOTs. In some cases it might have been meant as
43 > a transitional thing, until all consumers are ported to gtk3, but it
44 > has been lingering on due to consumer apps not being ported or we
45 > haven't yet noticed to remove the gtk2 support in the library package.
46 >
47 > Now these are libraries, and despite some USE flag confusion, it's not
48 > a huge issue, because consumers are USE depending on what is required.
49 > This all is written out in
50 > https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
51 > since the GNOME project pages moving to wiki, and also long before that
52 > in GuideXML era, and we've pointed people towards that.
53 >
54 > And then we have applications that support building against either gtk2
55 > or gtk3.
56 > In most cases, any requests to provide the choice to have an
57 > application use gtk2 instead of gtk3 gets instantly marked as duplicate
58 > of https://bugs.gentoo.org/374057 but in some cases the maintainer has
59 > chosen to provide this choice for now, and here is the problem - we
60 > don't really have a good agreed on way to name such a choice in USE
61 > flags, if we should provide such a choice at all.
62 >
63 > USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
64 > USE=gtk and it being problematic. The GNOME team shall probably veto
65 > such USE flag usage if we are deemed to have such an authority as gtk+
66 > maintainers, unless we rework it all in expectations of gtk2 corpse
67 > being carried around for a decade as well... I have quite a few bugs
68 > against packages to file already for this, afair.
69 >
70 > I kind of like what firefox did there, going in the spirit of the
71 > force-openrc flag we have for avoiding systemd dependency, even if it
72 > currently means worse user experience. So if we provide such a choice
73 > for apps at all, I might agree to USE=force-gtk2 for this for apps. And
74 > we would like to eventually (or immediately) p.use.mask this and once
75 > it's 2017 and gtk2 truly dead and buried and full of known security
76 > holes, get rid of it again.
77 > But this highlighted the inconsistency we are having, ending up with QA
78 > initiated bug https://bugs.gentoo.org/581662
79 >
80 > tl;dr and my proposal would be the following:
81 >
82 > * USE=gtk means providing support for GTK+; because we don't have a
83 > USE=gui, this also means "provide a GUI version built on top of gtk+"
84 > for packages where a GUI is optional.
85 >
86 > * USE=gtk3 may be used only for controlling extra libraries to be
87 > shipped for gtk3 support (the extra library file will link to gtk3),
88 > _in addition_ to gtk2 version. This is a temporarily measure until gtk2
89 > support can be dropped and it will only ship gtk3 version of the
90 > library. This gives a flag to be able to USE depend on by gtk3 apps.
91 > This leaves the question about the opposite open, however. This is why
92 > USE=gtk2 would be bad for apps, maybe we need to use it for this
93 > library case, when gtk3 version is primary and we just have 1 app
94 > remaining that needs the gtk2 version or something.
95 > The concept of library is broad here, covering also gtk theme engines
96 > (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and
97 > modules (e.g caribou, libcanberra)
98 >
99 > * Applications may only use a gtk2 based stack or gtk3 based stack in a
100 > given version/revision. gtk3 is strongly preferred when it is deemed to
101 > not have any regressions compared to gtk2 build, but the choice is
102 > ultimately with the maintainer. Once the application converts to using
103 > gtk3 in our distribution, it should try hard to stay that way in
104 > upcoming versions as well.
105 >
106 > * Some exceptions to the above may exist under heavy consideration,
107 > especially in cases where the toolkit usage is complex and may have
108 > some issues for some, but in general gtk3 support is deemed good by
109 > upstream. Most notable here would be browsers like firefox and
110 > chromium, which are using gtk dependency more for emulating the theme
111 > it uses, rather than using it as its real toolkit. If such exceptions
112 > are allowed, the USE flag naming here must be consistent amongst the
113 > exceptions. My proposal would be USE=force-gtk2 then, as I have no
114 > better ideas without stomping on the USE=gtk{2,3} historical meaning.
115 >
116 >
117 > When arguing in favor of supporting gtk2 builds more for apps, please
118 > do keep in mind that gtk2 really is pretty much dead. And no, MATE,
119 > XFCE and others are NOT continuing its support; they are just slow in
120 > fully converting to gtk3, but they are doing so and I expect both of
121 > those to be fully done this year, around autumn.
122 > If the issue is political or just a general gnome3 or gtk3 hate, then I
123 > would ask you to keep your political opinions or hate outside this
124 > thread and go contemplate on more important life issues.
125 > If the issue is lack of themes, then I would like you to help package
126 > more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
127 > themes shouldn't be breaking anymore beyond this point, theoretically.
128 > And gtk3 theme packages should pretty much just be CSS files and some
129 > metadata. Though we have yet to get over that bumpy thing yet (a main
130 > reason gtk3.20 isn't in main tree yet).
131 >
132 > Thoughts? Agreements? Suggestions?
133 > I'm particularly interested in QA opinion here. I believe WilliamH
134 > wanted to spearhead this from their side.
135 >
136 >
137 > Regards,
138 > Mart Raudsepp
139 > Gentoo developer, GNOME team
140 >
141 As far as I'm concerned, if any package I maintain offers both gtk2 and
142 gtk3 support, it would be irresponsible for me to *not* offer that
143 choice. Gentoo is about flexibility and giving power to the user. Choice
144 is a central part of that, and basically *the* reason I switched to
145 Gentoo or bothered to become a developer.
146
147 GTK3 might be fine for some, or in some applications. In my experience,
148 the theme is terrible (and a, frankly, half-assed promise from upstream
149 that they'll keep the API stable is not reassuring given their history
150 of quicksand APIs), scrollbars resize and disappear, the file choosing
151 dialog is worse, and some features from GTK2 were dropped altogether. If
152 GTK3 was largely a superset of what GTK2 offered, had better theming,
153 was more stable, etc, I don't think any of us would be debating much
154 about it. The fact of the matter is GTK3 has been handled poorly by
155 upstream. That's evidenced by the sheer amount of pushback they've
156 received from both users and developers, and the fact that yet again
157 we're having a discussion about dropping GTK2. Some projects that used
158 to use GTK are also switching to Qt due to the ever-changing APIs. The
159 LXDE team is one such team as they are working on LXQt.
160
161 You mentioned that there are security concerns that haven't been fixed
162 in GTK2. Can you link to some? If they're so bad, why haven't we seen
163 GLSAs about them?
164
165 You also mentioned that Mate and XFCE won't be supporting GTK2. Got any
166 links there?
167
168 Ultimately I don't care about the USE-flag naming problem. I'm in favor
169 of USE="gtk" meaning "support the latest gtk version". That's sane and
170 fair behavior. Using "gtk2" and "gtk3" for library support makes sense,
171 just like qt4 and qt5. Changing "gtk2" to "force-gtk2" in library
172 consumers is fine, too. As long as we don't get people telling others
173 that their choices, as developers or users, aren't important and
174 attempting to get GTK2 dropped from the tree altogether. If it compiles
175 and it works, there's no good reason to drop it yet.
176
177 I will maintain GTK2 compatibility in any package I maintain until GTK2
178 simply stops working altogether. It's what the users deserve and is most
179 representative of my upstreams. If you want to discuss USE flag name
180 changes, I'm all eyes. As long as we agree on something tree-wide.
181
182 Lastly...
183
184 > Some exceptions to the above may exist under heavy consideration,
185 > especially in cases where the toolkit usage is complex and may have
186 > some issues for some, but in general gtk3 support is deemed good by
187 > upstream.
188
189 Of course upstream is going to say support is good. Consider the source.
190 If they only write the toolkit and don't build real-world applications,
191 with real users, around it, how can their opinion be trusted? Also
192 consider said source's history. No upstream that I've spoken with has
193 relished working with GTK3. Maybe that will change with 3.20, if it's as
194 good as GNOME upstream is claiming. I'll be part of the group that sits
195 and waits. Results matter to me more than empty promises.
196
197 Just my two cents.
198
199 ~zlg
200
201 --
202 Daniel Campbell - Gentoo Developer
203 OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
204 fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6

Attachments

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

Replies

Subject Author
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation NP-Hardass <NP-Hardass@g.o>