Skip to content

Draft: Resolve critical bug #1065022 and related fallout

Simon McVittie requested to merge wip/1065022 into debian/latest

I believe this is ready for review, but I have not yet put this through the systematic testing that our quality expectations require for production-quality uploads (sbuild on native- and cross-architectures, autopkgtest under qemu and lxc, piuparts) because that takes approximately 2 hours on my current hardware, so it is possible that additional changes will be required. If so, I apologise for wasting reviewers' time.

Because my upload pipeline is relatively slow, I would prefer it if reviewers could make it clear whether any deficiencies are considered to be experimental upload blockers, unstable upload blockers, or merely nice-to-have. If only nice-to-have changes are requested, then I will not necessarily restart the release process for them.

  • d/libglib2.0-0t64.preinst: Remove libglib2.0-0 postrm to avoid file loss

    During the migration from libglib2.0-0 to libglib2.0-0t64, the package that is responsible for "owning" /usr/lib/*/gio/modules/giomodule.cache and /usr/share/glib-2.0/schemas/gschemas.compiled changed from libglib2.0-0 to libglib2.0-0t64. Because dpkg does not have an equivalent of RPM's %ghost files, the ownership of these files is managed by social convention rather than by the package management system.

    Unfortunately, libglib2.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 those files, and so will remove both files during purge (and giomodules.cache also during remove) in accordance with the requirement that installing and then removing and purging a package must not leave unowned files behind. This causes most applications that depend on GSettings schemas to crash with an assertion failure, until the next time the glib-compile-schemas trigger happens to be run; it will also cause functionality loss for applications that depend on GIO modules.

    To disarm the problematic maintainer script, delete it during the new package's preinst. This is (probably) a Policy violation, but seems like the least-bad exit strategy from the unacceptable situation we have found ourselves in.

    A subsequent commit will improve the postrm so that if we find that we need to migrate from libglib2.0-0t64 to libglib2.0-0xyz or libglib-2.0-0 at some point in the future, similar efforts will not be needed.

    Closes: #1065022

  • d/tests: Add a manual reproducer for #1065022

    Sorry, I do not have sufficient spoons right now to make this into a proper autopkgtest so that it can be run for every upload. My experience from doing similar things in nss-mdns is that an autopkgtest that goes back in time and installs previous suites' packages comes with a significant maintenance cost.

  • d/libglib2.0-0t64.postrm: Only clean up giomodule.cache during purge

    This matches the behaviour that we have had for gschemas.compiled since commit c8b28bc3 "debian/libglib2.0-0.postrm.in: Only remove the compiled schemas on purge", and with similar reasoning: if we remove this file during remove, then during upgrades there is a window between old-postrm and new-postinst during which giomodule.cache is missing. This will result in applications that require a GIO module (for example for TLS, proxy discovery or non-local filesystems) failing to load it, which seems undesirable.

    The impact is less serious than for GSettings schemas, but if we can avoid it, it seems like we should.

  • d/libglib2.0-0t64.postrm: Avoid recurrence of #1065022 in the future

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

    This implementation is based on the assumption that GLib will most likely continue to ship helper executables in ${libdir}/glib-2.0; or that if upstream carries out a major ABI break (unlikely to happen soon due to its extensive impact), they will make it fully parallel-installable, with ${datadir}/glib-3.0/schemas and ${libdir}/gio-3.0/modules, in which case the old version can continue to maintain or delete its caches without impacting the new version.

  • d/tests/1065022-futureproofing: Add a test for recurrence of #1065022

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

    This test-case depends on several implementation details of dpkg-repack and libglib2.0-0t64, and will likely fail in a non-minimal chroot/container (if there are foreign-architecture instances of libglib2.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.

  • Update changelog

Merge request reports