GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 17, 2020 20:59 UTC (Thu) by mattheww (guest, #108205)
In reply to: GTK 4.0 by smcv
Parent article: GTK 4.0

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

to post comments

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.