Technically, Gtk2 and Gtk3 are two different toolkits with a similar name. It's a completely different thing that Red Hat is trying to make us believe that GTK3 is an improved successor of GTK2. It isn't. It never has been.
GTK3 has been very much unstable, full of API breaks and annoyances from the get-go. It's slower due to CPU bloat under certain circumstances, eats up more RAM and is suffering from a serious UX dumbing down to the level of consumer devices like smartphones thus being made less suitable for desktop. Anti-features like mandatory recursive search <https://gitlab.gnome.org/GNOME/gtk/-/issues/839> in File Dialog have also been introduced. GTK3 was marked stable in many distros despite it wasn't stable at all. Software creators and package maintainers didn't want to migrate to a poorly designed, underdeveloped, buggy graphical toolkit. They either moved forward to Qt or stayed with Gtk2. A famous precedent case is the cancelled GTK3 migration of Audacious. They went back to Gtk2 then moved forward toward Qt. There must be a cooperation among Linux maintainters outside of Red Hat to save Gtk2 and provide security updates and some critical bug fixes on the maintainer level. On Sun, Oct 25, 2020 at 12:43 PM Simon McVittie <s...@debian.org> wrote: > On Sat, 10 Oct 2020 at 09:11:23 -0700, Sean Whitton wrote: > > Hello GNOME team, > > Note that pkg-gnome-maintainers receives bugmail etc. for the entire > GNOME suite, and most (all?) GNOME maintainers aren't subscribed to that > particular fire hose (we get bug mail for packages of interest, or for > all GNOME packages, via tracker.debian.org instead). Our discussion list > is debian-gtk-gnome; I only saw this because I happened to follow the > link on a removal notification for one of the GTK2 mass-bug-filing mails. > > > The FTP Team are starting to see removal requests for packages which > > use GTK2 and are unlikely to be ported to GTK3, but are not RC-buggy. > > Examples are #968204 and #968283. > > > > I read your bug report against one of those two packages and smcv writes > > > > 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. > > > > My interpretation of this is that use of GTK2 is not really grounds for > > removal by itself, because there is no removal of GTK2 planned for the > > time being. > > Yes. As I said in the mass-bug-filing, I think use of GTK 2 is a bug, > but not release-critical for bullseye. Depending what happens in the > next 1-2 years, it might be RC for bookworm - I don't know. > > However, if a package hasn't been able to move from GTK 2 to GTK 3 in > the time since GTK 2 was superseded (about a decade), that's a data point > for assessing how actively maintained it is, both upstream and in Debian. > > > So maintainers who don't want to deal with a package which > > is not likely to be updated for newer versions of GTK (which is fair > > enough) should orphan rather than request removal. > > Not necessarily: a package's maintainer is in a good position to assess > whether that package has a future in Debian, and whether it's suitable for > inclusion in a stable release. I think we need to distinguish between > "I think this package is suitable for Debian, but I can't/won't > maintain it" (orphaning) and "from my knowledge as maintainer, I think > this package is unsuitable for Debian" (RM: RoM). > > There's little point in orphaning a package if the most likely outcome > is that several weeks or months later, someone with less knowledge of > this particular package has to spend time on deciding that *now* it's > time to remove it. > > smcv > >
