On Fri, 09 Jan 2026 at 13:26:17 +0000, Adam Sampson wrote:
"Jonathan Dowland" <jmtd@debian.org> writes:This is perhaps the best place to start asking: who (else) is interested in picking up GTK2?
Adopting GTK2 in Debian (and only in Debian) isn't really a solution here, because GTK2 has been dead upstream for years, so there will be no new releases (or even commits) from which to take bug fixes. Upstream has moved on to GTK3, and then GTK4.
If someone adopts it in Debian, either they'll be its de facto upstream (but with a more difficult workflow for applying changes than if they were genuinely the upstream), or it'll be in the same position as other dead-upstream software, which seems to have a tendency to soak up a disproportionate amount of time outside the immediate package (for example by blocking transitions, FTBFS or miscompilation with newer compilers, forcing old dependencies to stay in the archive, and so on).
Forking it and maintaining the fork as a new upstream would be one way out of that, but obviously is more work.
Having a version of GTK 2 outside Debian, in a PPA-like sidecar repository that *works with* Debian but is not *part of* Debian, would be another way out - that would make it more obviously the sidecar repository maintainer's responsibility to keep it working, without letting it be a blocker for transitions and similar changes in the main distro. This is effectively what happened in Arch when it was moved from Arch to the AUR, for example.
I hope that in the medium to long term, Debusine repositories can become an easy way to have things that *work with* Debian (including Debian stable) but are not *part of* Debian. I've mostly been thinking about this in the context of fast-moving leaf packages that don't have enough long-term support to be suitable for a stable release, such as games and some of the more rapidly-iterating servers (the fasttrack use-case), but a similar approach seems equally good for slow-moving software and its legacy dependencies.
For anybody who is, it would be worth noting that the Ardour DAW project maintain a (renamed and slightly extended) version of GTK+ 2 as part of their repository: https://git.ardour.org/ardour/ardour/src/branch/master/libs/tk
If it has a broadly GTK-2-compatible API and ABI, and is maintained, then this might well be a better basis for something GTK-2-compatible than the actual GTK 2 is.
smcv