Ideally src:gtk4 would take over gtk-update-icon-cache on all
architectures, but it isn't buildable on all -ports architectures yet,
and the -ports architectures are more susceptible to packages temporarily
disappearing.
This package name was Ubuntu-specific, and was dropped since 45.0-4
(the Debian version of a-i-t has a Provides for a-i-t-full). Use a
versioned build-dependency so that we definitely have all of the
necessary icons to run tests successfully.
Thanks: Heinrich Schuchardt
This is mostly the GIR XML, which must be in an arch-dep package
as specified by the GObject-Introspection mini-policy. Keeping it
in /usr/share means that it can at least be shared between multiple
installed multiarch instances.
If at some point in the future we have another transition as extensive
as time64, then libgtk-3-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk-3-0xyz. If that
happens, we need to avoid deletion of immodules.cache, otherwise we
will have another bug similar to #1065494.
This implementation is based on the assumption that third-party input
method modules for GTK 3 will depend on GTK 3, therefore we should not
need to clean up the IM modules cache unless/until we reach the point
of having no IM modules installed.
If at some point in the future we have another transition as extensive
as time64, then libgtk-3-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk-3-0xyz. If that
happens, we need to avoid deletion of immmodules.cache, otherwise
we will have another bug similar to #1065494.
This test-case depends on several implementation details of dpkg-repack
and libgtk-3-0t64, so it might need to be adjusted in the future. As
a result, I have marked it as flaky, so that failures in the official
autopkgtest environment will not be considered a release-critical bug
that stalls migration and requires immediate intervention by maintainers.
During the migration from libgtk-3-0 to libgtk-3-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-3.0/3.0.0/immodules.cache
changed from libgtk-3-0 to libgtk-3-0t64. Because dpkg does not have an
equivalent of RPM's %ghost files, the ownership of this file is managed
by social convention rather than by the package management system.
Unfortunately, libgtk-3-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for this file, and so
will remove it during purge (and in fact also during upgrades) in
accordance with the requirement that the package must not leave unowned
files behind. This causes input methods to be non-functional in GTK apps
until the next time the gtk-query-immodules-3.0 trigger happens to be run.
To disarm the problematic maintainer script, delete it during the new
package's preinst, similar to what was done for GLib in response
to #1065022.
A subsequent commit will improve the postrm so that if we find that we
need to migrate from libgtk-3-0t64 to libgtk-3-0xyz at some point in
the future, similar efforts will not be needed.
Closes: #1065494
