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
our users to keep shipping it in new releases.
Can you expand on why? (If it ins't covered by your existing points
below)
If you find any of the remaining rdeps useful, there's time to port
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,
hexchat, amsynth, pidgin), but I'm just one weirdo: to truly assess the
impact I think we need to x-ref the list against popcon and similar such
exercises.
There is 0 chance of either hexchat or openjdk-8 being ported from GTK2
upstream. In general I think the delta of a port would also be
unreasonably large to carry in packaging. openjdk-8 is an odd one
because it's being deliberately kept out of stable releases, and is only
in sid. (disclaimer: I work on OpenJDK 8 upstream.) For hexchat, I
should eventually just switch IRC client. For pidgin, there is an
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
to GTK2, in many ways. They're not just an evolution of it. They are
simply not equivalent: they have different design choices. Porting from
GTK2 is not mechanical, it could require programs to make fundamental
design changes. The GTK and GNOME folks have made some choices that are
theirs to make (e.g. CSDs) that not everyone agrees with, and that's
their right to do, but I suspect some of the apps still using GTK2 are
doing so because they have differences of opinion there.
As for running external software, as you say, that is external, so
GTK+2 can be shipped externally as well if needed.
I wish for Debian to be a good base platform for running external
software.
We don't ship every old library just because someone could make use of
it. There is a maintenance cost to that. See e.g. QT4, libsdl1.2 and so
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
that we apply even-handedly to every library, and that not every library
is of equal significance. (FWIW I objected to QT4's removal at the
time.)
Perhaps those old packages also need us to ship GCC 5 or an old cmake.
That's a slippery slope.
I'm not asking to re-introduce stuff we've already dropped, and I
haven't suggested we should be able to *build* external
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
apples and oranges.
--
👱🏻 Jonathan Dowland
✎ [email protected]
🔗 https://jmtd.net
