Bug#1125507: gtk2-engines-pixbuf: removal leaves immodules.cache behind

[Simon McVittie]

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 at 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