Re: MBF: Removal of GTK2 from forky

On Fri Jan 9, 2026 at 10:14 AM GMT, Emilio Pozuelo Monfort wrote:
> (with my Release Team hat on)

I welcome the release team's perspective on the issue!

> If GTK+2 is dead upstream for so long, then it'd be a disservice to=20
> our users to keep shipping it in new releases.

Can you expand on why? (If it ins't covered by your existing points=20
below)

>If you find any of the remaining rdeps useful, there's time to port=20
>those over to GTK+3 or GTK+4.

The list of affected packages that Matthias has provided is enormous:
149 programs. Just glancing at it I see several that I use (openjdk-8,=20
hexchat, amsynth, pidgin), but I'm just one weirdo: to truly assess the=20
impact I think we need to x-ref the list against popcon and similar such=20
exercises.

There is 0 chance of either hexchat or openjdk-8 being ported from GTK2=20
upstream. In general I think the delta of a port would also be=20
unreasonably large to carry in packaging. openjdk-8 is an odd one=20
because it's being deliberately kept out of stable releases, and is only=20
in sid. (disclaimer: I work on OpenJDK 8 upstream.) For hexchat, I=20
should eventually just switch IRC client. For pidgin, there is an=20
upstream effort to move to GTK4. But that brings me to my next point:

I think GTK4 (and to a lesser extend GTK3) are fundamentally different=20
to GTK2, in many ways. They're not just an evolution of it. They are=20
simply not equivalent: they have different design choices. Porting from=20
GTK2 is not mechanical, it could require programs to make fundamental=20
design changes. The GTK and GNOME folks have made some choices that are=20
theirs to make (e.g. CSDs) that not everyone agrees with, and that's=20
their right to do, but I suspect some of the apps still using GTK2 are=20
doing so because they have differences of opinion there.

> As for running external software, as you say, that is external, so=20
> GTK+2 can be shipped externally as well if needed.

I wish for Debian to be a good base platform for running external=20
software.

>We don't ship every old library just because someone could make use of=20
>it. There is a maintenance cost to that. See e.g. QT4, libsdl1.2 and so=20
>many others that could been have kept for similar reasons.

I think it's important to recognise that we don't have a cast-iron rule=20
that we apply even-handedly to every library, and that not every library=20
is of equal significance. (FWIW I objected to QT4's removal at the=20
time.)

>Perhaps those old packages also need us to ship GCC 5 or an old cmake.=20
>That's a slippery slope.

I'm not asking to re-introduce stuff we've already dropped, and I=20
haven't suggested we should be able to *build* external=20
legacy/historical software.

> Note that GTK+3 was released in 2011.

As per my note above, in many ways the different GTK versions are like=20
apples and oranges.

--=20

=F0=9F=91=B1=F0=9F=8F=BB	Jonathan Dowland
=E2=9C=8E	 [email protected]
=F0=9F=94=97	https://jmtd.net