On Thu, 15 Jan 2026 at 08:45:37 +0100, Paul Gevers wrote:
During a run of $(apt autoremoval) gtk2-engines-pixbuf got removed
from my system. During the removal I saw this:
Removing gtk2-engines-pixbuf:amd64 (2.24.33-10)…
dpkg: warning: while removing gtk2-engines-pixbuf:amd64, directory
'/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0' not empty so not removed
I checked the directory and it contains this:
paul@toba ~ $ ls -al /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/*
-rw-r--r-- 1 root root 2027 Apr 30 2025
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules.cache
This is conceptually part of the libgtk2.0-0t64 package, and is left
over from removing (but not purging) libgtk2.0-0t64. It is deleted by
purging libgtk2.0-0t64, although only if there are no out-of-tree GTK IM
modules remaining.
It is actually nothing to do with gtk2-engines-pixbuf, which ships a
different sort of GTK plugin (an engine rather than an IM module) in a
different subdirectory.
Historically GTK IM modules have all depended on GTK itself (and at the
shared-library DT_NEEDED level, they still do) but in recent years we
have been suppressing that dependency in some of them, in an effort to
avoid circular dependencies. For example, libgtk2.0-0t64 Recommends
ibus-gtk, because that package is necessary in order for GTK 2 to have
the expected input behaviour on a GNOME or GNOME-like desktop
environment. However, that Recommends means that if ibus-gtk had a
Depends on libgtk2.0-0t64, then those two packages would never be
autoremoved, because each of them would keep the other referenced. I'm
not sure at what time the immodules cache can safely be removed in this
situation: it's possible that it will never get removed in some corner
cases (if you purge libgtk2.0-0t64 while an input-method package like
ibus-gtk is still installed).
We need to be careful about the circumstances under which we'll remove
the immodules cache because when a library migrates to a different
binary package (as GTK had to do during the time64 transition), it's
easy to get file-loss RC bugs like #1065493 if the packaging under the
old name didn't anticipate this possibility. Given the choice between an
unnecessary file remaining present after purge in some corner-case
situations, and a necessary file being deleted and breaking the user's
desktop environment during upgrades, I'd consider the former to be the
less-bad option.
The ideal solution to this would be some sort of reference-counting: a
way to declare that
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules.cache conceptually
belongs to each of libgtk2.0-0, libgtk2.0-0t64 and a hypothetical future
libgtk2.0-0xyz, and should automatically be deleted after the number of
packages that claim it drops from 1 to 0. Or, maybe, a way to declare
that /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules.cache is closely
related to /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/, and
should automatically be deleted after
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/ goes away.
Unfortunately we can't easily achieve those semantics via maintainer
scripts, because GTK's maintainer scripts get deleted when GTK is
purged; so if we miss our chance to delete the immodules.cache because
it is being kept referenced by an IM module, we won't get another chance
later.
(Possibly we could introduce a lower-level package that is depended on
by libgtk2.0-* and all IM modules, and is only responsible for the
cleanup of immodules.cache and similar files? But if every library with
plugins did that, that's a lot of trips through NEW, and a lot of small
packages making the Packages metadata larger.)
GTK 3 and 4 have similar patterns, and so does GLib, for their own
plugins; so if this is considered to be a serious problem then it will
likely need to be addressed somehow even if GTK 2 is removed from forky.
smcv
