GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 17, 2020 2:12 UTC (Thu) by ebassi (subscriber, #54855)
In reply to: GTK 4.0 by pabs
Parent article: GTK 4.0

I'm sure that Linux distributions will keep GTK2 in their repositories for a long time; I think some of them still ship GTK1, which hasn't been touched in nearly 20 years.

to post comments

GTK 4.0

Posted Dec 17, 2020 3:11 UTC (Thu) by pabs (subscriber, #43278) [Link] (13 responses)

I note that Debian is planning on removing GTK2 for Debian 12 bookworm, to be released in 2-3 years time and starting sometime next year after the Debian 11 bullseye release.

https://bugs.debian.org/947713

The GTK1 transition also saw the loss of some things, the one that I remember was the GTK interface for nethack, which still hasn't recovered a GTK interface of any era.

GTK 4.0

Posted Dec 17, 2020 3:18 UTC (Thu) by ebassi (subscriber, #54855) [Link] (5 responses)

Then this is a great chance to start using Flatpak to ensure that GTK2 (and GTK1!) applications can still be used on newer versions of your favourite Linux distribution.

GTK 4.0

Posted Dec 17, 2020 3:31 UTC (Thu) by pabs (subscriber, #43278) [Link] (4 responses)

Aren't the GTK2/GTK1 Flatpak runtimes going away too? Either way, the maintainers of software still depending on GTK2/GTK1 haven't bothered to migrate to GTK3/4, I doubt they will bother with Flatpak packaging either.

GTK 4.0

Posted Dec 17, 2020 9:25 UTC (Thu) by smcv (subscriber, #53363) [Link]

If GTK 2 apps are sufficiently important to you, I'm sure your help would be appreciated. The people packaging GTK 2 apps as Flatpak apps don't *have* to be their upstream maintainers, any more than the people packaging GTK 2 apps for Debian have to be their upstream maintainers.

It's also entirely possible to build Flatpak-style runtimes from Debian packages: https://salsa.debian.org/smcv/flatdeb can do this, and is used to build the Debian-10-based Steam Runtime v2 (which is not currently distributed as a Flatpak runtime itself, but is "the right shape" to be used as one). GTK 2 is available in Debian 10 and will be in Debian 11. I don't currently have enough bandwidth to be trying to build production-quality Debian runtimes alongside my other responsibilities, or to set up, sysadmin and fund a suitable hosting platform (CDN?) for distributing them, but someone could.

GTK 4.0

Posted Dec 17, 2020 14:16 UTC (Thu) by ebassi (subscriber, #54855) [Link] (2 responses)

> Aren't the GTK2/GTK1 Flatpak runtimes going away too?

Why would it matter? You can bundle the latest GTK2 release and build it alongside your GTK2 application. I mean: that's the entire point of Flatpak.

GTK 4.0

Posted Dec 18, 2020 6:50 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

But GTK2 has reached end of life, so you can’t bundle it. If you say, this end of life stuff is nonsense, there is no reason not to keep shipping the library, then you may equally well ship it as an rpm or deb package. I don’t see that using Flatpak makes a difference either way.

GTK 4.0

Posted Dec 18, 2020 12:23 UTC (Fri) by smcv (subscriber, #53363) [Link]

> But GTK2 has reached end of life, so you can’t bundle it

GTK 2 reaching end of life means that the GTK developers are no longer willing to take responsibility for it. If you *are* willing to take responsibility for it, or at least for the subset that's used in your application, then nobody is stopping you from doing so. (Indeed, the license is irrevocable, so nobody *can* stop you.)

> If [...] there is no reason not to keep shipping the library, then you may equally well ship it as an rpm or deb package

As a downstream maintainer, I'm not exactly enthusiastic about taking responsibility for GTK 2 longer than the upstream developers do, for approximately the same reasons they have announced its EOL: every hour I spend on maintaining GTK 2 is an hour I'm not spending on something more widely beneficial, or more rewarding.

Debian will continue to ship GTK 2 as a .deb for a while, but eventually we too will be unable or unwilling to take responsibility for it. If you want to ship a third-party .deb outside Debian, or bundle it in a Flatpak app, it's up to you to maintain that in a way you are happy with (it seems to me that bundling it in a Flatpak app would be a better way to make it clear what uses you are and aren't taking responsibility for, but how you use your time and effort is not up to me).

GTK 4.0

Posted Dec 17, 2020 7:25 UTC (Thu) by epa (subscriber, #39769) [Link]

The dillo web browser was using GTK 1, but moved to FLTK instead when GTK 1 died.

GTK 4.0

Posted Dec 17, 2020 9:45 UTC (Thu) by smcv (subscriber, #53363) [Link] (5 responses)

> planning on removing GTK2 for Debian 12 bookworm

The original bug report that you linked says "There are currently no concrete plans to remove GTK 2 from Debian, but I'm sure it will become necessary one day", and the subsequent mass-bug-filing template said "perhaps removing GTK 2 from Debian will never be feasible". I wouldn't call that a plan to remove GTK 2 from Debian 12, unless someone else has that plan and hasn't told me.

I would *like* to remove GTK 2 from Debian eventually, but the causality is the other way around: instead of "we want to remove GTK 2, and therefore the apps must switch or be removed", it's more like "if the apps switch or are removed, then we can remove GTK 2".

The mass bug filing seems to have had the desired effect in the sense that packages that *can use* GTK 2, but don't *need* GTK 2, have been taking the hint and disabling it (either by porting to GTK 3, or by disabling more minor features that need GTK 2 in an otherwise GTK 3 or non-GTK package).

Some maintainers have been taking the initiative to remove their packages that require GTK 2 from Debian. If the only reason is "there's a bug report pointing out that GTK 2 is deprecated", then I don't think that's necessary or desirable, but if the reasoning is "its use of GTK 2 is a symptom of being generally unmaintained", then that's no bad thing.

You might notice that I'm in the Uploaders for gmpc, which is a GTK 2 music player (mpd client). I regularly use it, and if it gets removed from Debian, it's more likely to be because it was written for old Vala compilers and depends on the rather obscure gob2 than because it uses GTK 2.

GTK 4.0

Posted Dec 17, 2020 20:59 UTC (Thu) by mattheww (guest, #108205) [Link] (4 responses)

I have a question:

Does Debian consider that GTK 2 is in the archive solely in order to support other Debian-packaged applications, or is also there so Debian's users can run their own programs which might have been written against GTK 2?

That is, if the day comes when the archive contains nothing that depends on GTK 2, will the maintainers automatically think "great, we can remove it now", or would they try to find out whether there are users who still want it for its own sake?

(I ask because I saw no sign of the latter when GTK 1 was removed.)

GTK 4.0

Posted Dec 18, 2020 1:41 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

Normally Debian doesn't consider packages not in Debian when doing removals, since the person requestion removal usually doesn't have visibility into that.

OTOH, sometimes we get old stuff reintroduced because external things use them, for example src:libudev0-shim was recently added reintroducing libudev0 as a compat shim for libudev1.

https://github.com/archlinux/libudev0-shim
https://packages.debian.org/libudev0

GTK 4.0

Posted Dec 18, 2020 10:27 UTC (Fri) by mattheww (guest, #108205) [Link] (1 responses)

It seems to me that Debian has something of a blind spot here. I don't
think the maintainers would consider removing, say, a COBOL compiler or
an R charting library because it had no reverse dependencies.

But when they're looking at a piece of software which historically did
have many things in the archive depending on it, it's as if there's a
default assumption that that was its only purpose.

GTK 4.0

Posted Dec 19, 2020 1:31 UTC (Sat) by pabs (subscriber, #43278) [Link]

Things get removed from Debian due to lack of reverse dependencies all the time. The first class of these are modules in various languages (Node/Python/Perl etc) that are often just removed by the respective language team when nothing in Debian uses them and they don't have significant popcon. The second class is things that gather an critical bug that is trivial to fix, often they will just be removed instead of fixing the bug. Unfortunately Debian QA folks are significantly deletionist, since removal is less effort in the long term than fixing issues.

I definitely agree with you that Debian has a blind spot around user feedback. Apart from popcon, we don't know how important each package is to our user-base, we don't have telemetry to automatically hear about common issues and we don't have a way to pro-actively reach all users (not just those on the mailing lists) to ask them to test issues/fixes etc, we can only react to bug reports, support requests etc.

GTK 4.0

Posted Dec 18, 2020 12:10 UTC (Fri) by smcv (subscriber, #53363) [Link]

> Does Debian consider that GTK 2 is in the archive solely in order to support other Debian-packaged applications, or is also there so Debian's users can run their own programs which might have been written against GTK 2?

A bit of both. If you're developing your own programs written against GTK 2, then when it eventually gets dropped from the archive, you're well-placed to pick up responsibility from its Debian maintainers and compile your own copy of GTK 2 alongside your programs, if that's what you need. We provide you with full source code, both for the library itself and the packaging, and even if its upstream developer no longer does; so if it has bugs that are a showstopper for your particular use, then you have the option of fixing them, even if the fix is an incompatible change and you end up maintaining a fork to go with your programs.

We can't maintain superseded libraries or other runtime environments forever with a finite number of developers, and I don't think we should pretend that we can. It seems better to have a clear signal that we are no longer taking responsibility for a particular library, giving people who depend on it a chance to either pick up responsibility for having their own version, or move away from it.

There's nothing particularly special about GTK here: as a distribution, we've done this in the past for GTK older than 2, Qt older than 5, Python 2 older than 2.7, Python 3 older than 3.9, Perl older than 5.32, Ruby older than 2.7, GStreamer older than 1.0, and many more.
(Version numbers taken from testing/unstable and the planned Debian 11 stable release; adjust downwards as appropriate for the Debian 10 stable release.)

In practice, an old .deb from an old Debian release will often install and work acceptably on a newer release (at your own risk, no support implied), so continuing to use an unsupported library doesn't *necessarily* mean compiling your own - but if you want bugs fixed, or if you want to rebuild against newer dependency ABIs, at some point that becomes your responsibility rather than the distribution's. Anything else is just not sustainable.

GTK 4.0

Posted Dec 20, 2020 8:53 UTC (Sun) by ms_43 (subscriber, #99293) [Link]

GTK 2 is on RHEL 7's list of Compatibility level 1 packages[0].

This is a very short list of packages, and gtk2 and motif are the only GUI toolkits in it.

For RHEL 8, gtk2 moved to Compatibility level 2, and notably there are no GUI toolkits in level 1 any more, while level 2 has gtk2, gtk3, motif, libXaw, qt5-qt5base.

So at a minimum Red Hat has promised to support gtk2 until RHEL9 EOL for paying customers.

[0] Compatibility level 1: APIs and ABIs are stable across three major releases (starting with RHEL 7)
https://access.redhat.com/articles/rhel-abi-compatibility...

[1] Compatibility level 2: APIs and ABIs are stable within one major release
https://access.redhat.com/articles/rhel8-abi-compatibilit...