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
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
Gilles, I have updated navit to the latest version at http://salsa.debian.org/jbicha/navit . I did this work because I noticed the new version claims to support Ubuntu Touch (which was https://github.com/navit-gps/navit/pull/1264 ) To get navit back into Debian Testing, we need to stop using gtk2. Therefore, I switched to using qt5 for graphics instead of gtk_drawing_area. I looked into using qt5_qml for the GUI also but it looks like there is a bug in navit's qml install, so it still uses the internal GUI. I added a new binary package for the qt graphics backend and removed the two gtk packages. I made the internal gui and qt graphics packages mandatory dependencies since they are both needed for the package to work. The buildsystem has an interesting feature where it uses xslt snippets to update the default XML file. Using the sailfish_qt5 template enables the qt5 graphics backend for us. Unfortunately, adding new binary packages means going through the Debian NEW queue so I needed to update debian/copyright. This project has a lot of copies of code from other projects that we don't need for our build so I added those to Files-Excluded to make debian/copyright a lot simpler to update. It looked to me like the sdl graphics backend works (in fact, that's the only reason we have it in Build-Depends). We could add another binary package for this but I don't know if there is much benefit. The opengl graphics backend still didn't seem to work. I didn't test a map because Navit's service to convert OSM data to the Navit format isn't working, but the UI otherwise seemed to work for me. I disabled the dbus feature because it's not enabled by default and it fixes a bug. I'm not sure if the geoclue feature is working correctly but it looks like navit supports multiple geolocation backends so I think this isn't a problem. The geoclue feature is relatively new in navit's history so that's probably why it wasn't enabled earlier. Thank you, Jeremy Bícha