Control: retitle -1 libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules
Ash Joubert wrote: > Workaround for me was to reinstall gsettings-desktop-schemas: > > # apt-get reinstall gsettings-desktop-schemas Yes, the workaround for this is to reinstall any package that carries GSettings schemas. gsettings-desktop-schemas is a common one, but actually any package that has files in /usr/share/glib-2.0/schemas/ should be equally good here. There is a related failure mode with a less dramatic impact that can be worked around by reinstalling either dconf-gsettings-backend, glib-networking or gvfs after the upgrade. On Thu, 29 Feb 2024 at 05:31:17 +0100, Christoph Anton Mitterer wrote: > Attached is the aptitude log. Please also check the apt logs, particularly /var/log/apt/term.log, which will tell us what actually happened (not just what aptitude planned to do, which is what the aptitude logs show). What I'm mainly interested in in is the order of these events relative to each other, during the upgrade transaction that added libglib2.0-0t64: - De-configuring libglib2.0-0 (it's OK if this is not present) - Preparing to unpack libglib2.0-0t64 - Processing triggers for libglib2.0-0t64 - Purging configuration files for libglib2.0-0 - Removing libglib2.0-0 - Setting up libglib2.0-0t64 - Unpacking libglib2.0-0t64 Ash, the same information from you would be useful. > [INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-2 ... > [REMOVE (PURGE)] libglib2.0-0:amd64 2.78.4-1 I think what has happened here is that because you are *purging* (and not just removing) the old libglib2.0-0, this code in the postrm is triggered: if [ "$1" = purge ] && [ -d /usr/share/glib-2.0/schemas ] && [ "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = 1 ]; then # This is the last multiarch variant to be removed, so drop the # architecture-independent compiled schemas rm -f /usr/share/glib-2.0/schemas/gschemas.compiled rmdir -p --ignore-fail-on-non-empty /usr/share/glib-2.0/schemas fi ... and then you have no GSettings schemas available any more, so anything that uses GSettings will crash. And then when you reverted the transition, you did the same thing in reverse: > [INSTALL, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1 ... > [REMOVE (PURGE)] libglib2.0-0t64:amd64 2.78.4-2 which would have the same problem. Removing libglib2.0-0 will also remove the GIO modules cache, even though it is (now) still being used by libglib2.0-0t64. That has a less dramatic impact, but will break glib-networking and gvfs, which would explain some bug reports we've seen recently where certificate validation in GLib apps stops working with a message about there being no trusted CAs. Unlike the code path for schemas, this *does* get triggered when libglib2.0-0 is removed-but-not-purged. This is code that has existed for over a decade, written with the assumption that the only time GLib would break ABI is if there was an upstream transition to libglib3.0 with completely parallel-installable paths. In the absence of a time machine, we can't go back and change it. Unfortunately at the moment I'm not seeing a way to fix this without a time machine: we can't go back and change the postrm of libglib2.0-0 in bookworm to have different behaviour. The only reliable solution I can immediately see would be for libglib2.0-0t64 to delete the postrm of libglib2.0-0 during its preinst (which is a Policy violation, and relies on the filesystem layout of dpkg internals). Steve, are you aware of any better options? For future versions of glib2.0, I can see a few ways this could be made more robust against in-place ABI transitions - but we can't retroactively make any of those changes in bookworm, because bookworm was already released, so I think we should defer discussion of those until after the immediate problem has been solved. smcv