Debian GNOME team announces intent to remove GTK 2 in Debian 14(lists.debian.org)
lists.debian.org
Debian GNOME team announces intent to remove GTK 2 in Debian 14
https://lists.debian.org/debian-devel/2026/01/msg00090.html
3 comments
My issue with this is not that they're getting rid of buggy applications they don't want to support. It's that GTK 2 itself is not buggy and has no problems. There are still plenty of people using GTK 2 applications and I personally wrote a handful of new GTK 2 applications over the last year. GTK 3 wasn't a replacement for GTK 2. Just like GTK 4 isn't a replacement for GTK 3. They're separate things.
Dropping buggy GTK 2 software applications: okay, understandable.
Droppping perfectly functional GTK 2 itself: not okay.
Other distros like Arch have well supported unofficial repos that still provide the GTK 2 package when it is needed. Debian does not. It does not hurt Debian at all to keep packaging GTK 2 itself and making it available. It is stable software and there have been no changes for decades besides a handful of compiler args to deal with changing compilers.
And GTK 2 does not need to support HiDPI or native Wayland. Just like all the Wayland programs do not support running on xorg or even other wayland compositors not sharing their wayland protocol extensions used. This is not actually a show stopper problem. It is consistent with other software's incompatibility with waylands and would only apply to those actually using GTK 2 applications and those demographics likely aren't wayland adopters.
Dropping buggy GTK 2 software applications: okay, understandable.
Droppping perfectly functional GTK 2 itself: not okay.
Other distros like Arch have well supported unofficial repos that still provide the GTK 2 package when it is needed. Debian does not. It does not hurt Debian at all to keep packaging GTK 2 itself and making it available. It is stable software and there have been no changes for decades besides a handful of compiler args to deal with changing compilers.
And GTK 2 does not need to support HiDPI or native Wayland. Just like all the Wayland programs do not support running on xorg or even other wayland compositors not sharing their wayland protocol extensions used. This is not actually a show stopper problem. It is consistent with other software's incompatibility with waylands and would only apply to those actually using GTK 2 applications and those demographics likely aren't wayland adopters.
I get the appeal of “it still works, so what’s the problem,” but from a distro’s point of view an unmaintained C toolkit with a big ABI surface is a problem. Even if GTK2’s code hasn’t changed, it still has to keep building across new compilers, hardening flags, toolchain transitions, security scans, etc.
Arch can shove that into community repos and say “you’re on your own.” Debian’s promise is different: if it’s in the archive, someone’s implicitly on the hook for it for years. At some point it’s more honest to drop it from main and let people who really want GTK2 own it via containers/Flatpaks/OBS, instead of making everyone else carry an orphaned toolkit forever.
Arch can shove that into community repos and say “you’re on your own.” Debian’s promise is different: if it’s in the archive, someone’s implicitly on the hook for it for years. At some point it’s more honest to drop it from main and let people who really want GTK2 own it via containers/Flatpaks/OBS, instead of making everyone else carry an orphaned toolkit forever.
The hard part is always the long tail and the installer. If the graphical Debian Installer still depends on GTK2, that’s a good reminder of how much distro plumbing quietly sits on old tech because “it works” and no one wants to touch it. My guess is we’ll see more distros take this approach: aggressively prune old toolkits from the main repos, and push truly unmaintained apps into containers/Flatpaks or community overlays instead of carrying a full compatibility stack forever.