This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
<https://bugs.debian.org/947713>). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes, for example ibus and mate-themes. If these
packages deliberately support GTK 2 even though it is deprecated, and
they also support GTK 3, then it is appropriate to mark this mass-filed
bug as wontfix for now. I have tried to exclude these packages from
the mass-bug-filing, but I probably missed some of them.

Regards,
    smcv

Hi,

my attempt to simply exclude those binaries that really need the GTK2
interface[1] showed that it seems to affect all binaries and nothing
useful is left if GTK2 would be removed.  Since the software is not
maintained upstream any more we probably need to drop the package
together with GTK2.

Kind regards
    Andreas.

[1] https://salsa.debian.org/med-team/seqtools/-/blob/master/debian/patches/no_gtk2%2B.patch

Hi. This is all FYI and does not require any action on your side :-)

The above attempt at dropping gtk2 was still in HEAD in the salsa repo
and made the package (or the repository) not to be in good shape.

Since I wanted to make a team upload, I've first done a "tidy up" commit
to put the repo in sync with version 4.44.1+dfsg-7.1 (i.e. the NMU
where the time_t transition happened).

This allowed me to add the missing tag for the NMU in a way which was
clearly visible when doing "git log".

The gtk2 commits, even if reverted, have not been lost because they
are still in the history, but if there is a real need to put them
somewhere in a way that they can be tested, I suggest using a branch.

Thanks.

Am Wed, Nov 26, 2025 at 10:00:29PM +0100 schrieb Santiago Vila:

Thank you.

We (obviously wrongly) assumed that packaging of those tools would be
simple.  So yes, using a branch would have been a cleaner way to go.

Thank you for cleaning up
    Andreas.

As announced [1], we are trying to remove gtk2 from forky. Therefore,
I am raising the severity of this issue.

[1] https://lists.debian.org/debian-devel/2026/01/msg00090.html

On behalf of the Debian GNOME team,
Jeremy Bícha

Do we have a fix for this? It seems we need to either re-write or drop
ClassicLadder.