Re: MBF: Removal of GTK2 from forky

On Fri, 09 Jan 2026 at 13:26:17 +0000, Adam Sampson wrote:
>"Jonathan Dowland" <[email protected]> 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