Gentoo Archives: gentoo-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation
Date: Fri, 27 May 2016 15:02:59
Message-Id: 20160527080202.2d30940f.dolsen@gentoo.org
In Reply to: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation by Mart Raudsepp
1 On Fri, 27 May 2016 17:21:06 +0300
2 Mart Raudsepp <leio@g.o> wrote:
3
4 > Hello,
5 >
6 > Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
7 > upstream, many applications still support only gtk2, have subtle
8 > issues with their gtk3 port, or support both, with some of our
9 > userbase clinging to gtk2 for dubious political or aesthetical
10 > reasons.
11 >
12 > For the latter cases, despite GNOME teams policy and strong preference
13 > on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
14 > working as good as gtk2), some cases exist where the maintainers want
15 > to provide such choice. In some cases it is understandable for a short
16 > while during transition, e.g firefox. In other cases, it is purely for
17 > the sake of providing the choice of working with a deprecated toolkit,
18 > apparently.
19 >
20 > My highly biased essay aside, we need to finally globally agree on
21 > what we do in this situation. If we allow this choice at all, only for
22 > special cases, or widespread. And if this choice is provided, how do
23 > we name the USE flag.
24 >
25 > Historically, for very good reasons in past and present GNOME team
26 > members opinion, USE=gtk has always meant to mean to provide support
27 > for gtk in general, not any particular version. This is opposite to
28 > what the Qt team has been doing.
29 > In our opinion, in a perfect world, only USE=gtk would exist, and no
30 > USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a
31 > perfect world, we have made use of USE=gtk3 for providing gtk3 support
32 > from library packages to mean to build gtk3 support. Sadly that
33 > overloads USE=gtk in many cases to then mean to build gtk2 support.
34 > This would ideally not be needed, as the package would instead be
35 > slotted and parallel installable for gtk2 and gtk3, which should be
36 > theoretically possible in all cases, because gtk2 and gtk3 may not
37 > live in the same process, so not the same library either.
38 > Due to some packages needing too much manpower effort to do such a
39 > split, USE flags are used in such a case.
40 > Good examples of such slot splits existing are for example the
41 > libappindicator stack. This used to be the case with almost all GNOME
42 > libraries as well, but most of them only provide gtk3 now, as gtk2 is,
43 > well, dead.
44 > Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to
45 > split up into separate SLOTs. In some cases it might have been meant
46 > as a transitional thing, until all consumers are ported to gtk3, but
47 > it has been lingering on due to consumer apps not being ported or we
48 > haven't yet noticed to remove the gtk2 support in the library package.
49 >
50 > Now these are libraries, and despite some USE flag confusion, it's not
51 > a huge issue, because consumers are USE depending on what is required.
52 > This all is written out in
53 > https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3
54 > since the GNOME project pages moving to wiki, and also long before
55 > that in GuideXML era, and we've pointed people towards that.
56 >
57 > And then we have applications that support building against either
58 > gtk2 or gtk3.
59 > In most cases, any requests to provide the choice to have an
60 > application use gtk2 instead of gtk3 gets instantly marked as
61 > duplicate of https://bugs.gentoo.org/374057 but in some cases the
62 > maintainer has chosen to provide this choice for now, and here is the
63 > problem - we don't really have a good agreed on way to name such a
64 > choice in USE flags, if we should provide such a choice at all.
65 >
66 > USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and
67 > USE=gtk and it being problematic. The GNOME team shall probably veto
68 > such USE flag usage if we are deemed to have such an authority as gtk+
69 > maintainers, unless we rework it all in expectations of gtk2 corpse
70 > being carried around for a decade as well... I have quite a few bugs
71 > against packages to file already for this, afair.
72 >
73 > I kind of like what firefox did there, going in the spirit of the
74 > force-openrc flag we have for avoiding systemd dependency, even if it
75 > currently means worse user experience. So if we provide such a choice
76 > for apps at all, I might agree to USE=force-gtk2 for this for apps.
77 > And we would like to eventually (or immediately) p.use.mask this and
78 > once it's 2017 and gtk2 truly dead and buried and full of known
79 > security holes, get rid of it again.
80 > But this highlighted the inconsistency we are having, ending up with
81 > QA initiated bug https://bugs.gentoo.org/581662
82 >
83 > tl;dr and my proposal would be the following:
84 >
85 > * USE=gtk means providing support for GTK+; because we don't have a
86 > USE=gui, this also means "provide a GUI version built on top of gtk+"
87 > for packages where a GUI is optional.
88 >
89 > * USE=gtk3 may be used only for controlling extra libraries to be
90 > shipped for gtk3 support (the extra library file will link to gtk3),
91 > _in addition_ to gtk2 version. This is a temporarily measure until
92 > gtk2 support can be dropped and it will only ship gtk3 version of the
93 > library. This gives a flag to be able to USE depend on by gtk3 apps.
94 > This leaves the question about the opposite open, however. This is why
95 > USE=gtk2 would be bad for apps, maybe we need to use it for this
96 > library case, when gtk3 version is primary and we just have 1 app
97 > remaining that needs the gtk2 version or something.
98 > The concept of library is broad here, covering also gtk theme engines
99 > (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and
100 > modules (e.g caribou, libcanberra)
101 >
102 > * Applications may only use a gtk2 based stack or gtk3 based stack in
103 > a given version/revision. gtk3 is strongly preferred when it is
104 > deemed to not have any regressions compared to gtk2 build, but the
105 > choice is ultimately with the maintainer. Once the application
106 > converts to using gtk3 in our distribution, it should try hard to
107 > stay that way in upcoming versions as well.
108 >
109 > * Some exceptions to the above may exist under heavy consideration,
110 > especially in cases where the toolkit usage is complex and may have
111 > some issues for some, but in general gtk3 support is deemed good by
112 > upstream. Most notable here would be browsers like firefox and
113 > chromium, which are using gtk dependency more for emulating the theme
114 > it uses, rather than using it as its real toolkit. If such exceptions
115 > are allowed, the USE flag naming here must be consistent amongst the
116 > exceptions. My proposal would be USE=force-gtk2 then, as I have no
117 > better ideas without stomping on the USE=gtk{2,3} historical meaning.
118 >
119 >
120 > When arguing in favor of supporting gtk2 builds more for apps, please
121 > do keep in mind that gtk2 really is pretty much dead. And no, MATE,
122 > XFCE and others are NOT continuing its support; they are just slow in
123 > fully converting to gtk3, but they are doing so and I expect both of
124 > those to be fully done this year, around autumn.
125 > If the issue is political or just a general gnome3 or gtk3 hate, then
126 > I would ask you to keep your political opinions or hate outside this
127 > thread and go contemplate on more important life issues.
128 > If the issue is lack of themes, then I would like you to help package
129 > more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
130 > themes shouldn't be breaking anymore beyond this point, theoretically.
131 > And gtk3 theme packages should pretty much just be CSS files and some
132 > metadata. Though we have yet to get over that bumpy thing yet (a main
133 > reason gtk3.20 isn't in main tree yet).
134 >
135 > Thoughts? Agreements? Suggestions?
136 > I'm particularly interested in QA opinion here. I believe WilliamH
137 > wanted to spearhead this from their side.
138 >
139 >
140 > Regards,
141 > Mart Raudsepp
142 > Gentoo developer, GNOME team
143 >
144
145 I'll be really sad when gtk2 is totally abolished in Gentoo. :(
146 I suppose I'll have to break down and switch to KDE maybe.
147
148 In my opinion the upstream gtk developers have gone somewhat bonkers
149 with their cartoonish changes to the look, feel and generally
150 un-intuitive user interface. The new file selector is irritating to use
151 despite getting all the old behaviour settings I know of set, the lack
152 of the ability to paste a path into it, forcing you to navigate
153 directory by directory, and other BS behaviour... Some apps even have
154 less functionality and usefullnes. I have a local copy of
155 dev-vcs/gitg-0.27 ebuild which I use daily which despite some
156 instability is far more useful than it's "modern" counterpart. I use
157 xfce4 for both work and my own workstation, and like it, but it's apps
158 are getting increasingly more corrupted by gtk3isms :(
159
160 So, I accept I'll not be liked by the gtk team for wanting to keep gtk2
161 around still.
162 --
163 Brian Dolbec <dolsen>

Replies

Subject Author
Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation "Canek Peláez Valdés" <caneko@×××××.com>