GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 17, 2020 9:45 UTC (Thu) by smcv (subscriber, #53363)
In reply to: GTK 4.0 by pabs
Parent article: GTK 4.0

> 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.

to post comments

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.