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
