Based on the reproducer I added to src:glib2.0 for the similar bug #1065022.
This one is simpler, because only architecture-specific multiarch files
are affected.

During the migration from libgtk2.0-0 to libgtk2.0-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-2.0/2.10.0/immodules.cache
changed from libgtk2.0-0 to libgtk2.0-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, libgtk2.0-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-2.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 libgtk2.0-0t64 to libgtk2.0-0xyz at some point in
the future, similar efforts will not be needed.

Closes: #1065493

This avoids input methods becoming briefly unavailable during upgrades.

If at some point in the future we have another transition as extensive
as time64, then libgtk2.0-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk2.0-0xyz. If that
happens, we need to avoid deletion of immmodules.cache, otherwise
we will have another bug similar to #1065493.

This test-case depends on several implementation details of dpkg-repack
and libgtk2.0-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.

If at some point in the future we have another transition as extensive
as time64, then libgtk2.0-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk2.0-0xyz. If that
happens, we need to avoid deletion of immodules.cache, otherwise we
will have another bug similar to #1065493.

This implementation is based on the assumption that third-party input
method modules for GTK 2 will depend on GTK 2, therefore we should not
need to clean up the IM modules cache unless/until we reach the point
of having no IM modules installed.

gtk+2.0 release 2.24.33-4 for unstable (sid)

(maintainer view tag generated by dgit --quilt=unapplied)

[dgit distro=debian split --quilt=unapplied]

* tag 'debian/2.24.33-4':
  Release to unstable
  Update changelog
  d/libgtk2.0-0t64.postrm: Avoid recurrence of #1065493 in the future
  d/tests/1065493-futureproofing: Add a test for recurrence of #1065493
  d/libgtk2.0-0t64.postrm.in: Only clean up immodules.cache during purge
  d/libgtk2.0-0t64.preinst: Remove libgtk2.0-0 postrm to avoid file loss
  d/tests/manual/1065493.sh: Add a manual reproducer for #1065493

for code using these functions

Gbp-Dch: Full