Hey Simon.
On Thu, 2024-02-29 at 10:33 +0000, Simon McVittie wrote:
> 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.
So the advise for "end users" is to simply re-install one package of
both groups and everything should be cleaned up again?
> 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).
See the attached files.
term.log.{1,2} are NOT rotated files.
.1 is the first try, where I've upgraded all packages at once in the
beginning and then did lots of subsequent "downgrades", trying to find
out where the problem is.
After that I restored the whole root-fs from a btrfs snapshot that I
had made by coincidence just before.
.2 is the whole upgrades but in several steps, with an number of re-
installs (from the *t64 packages, just to be sure that all files are
there), eventually also re-installing libglib.
> 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
Guess that should all be in the APT term logs? If not, don't hesitate
to poke me with a stick.
> > [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.
I see. But isn't one more or less supposed to purge?
I mean if there would e.g. ever be a libglib3, and libglib2.0-0 had
e.g. some conffiles (or manually created) files that where still neeed
in libglib3 but some that are obsolete... one would eventually need to
purge in order to clean those up.
> 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.
Would that (cache) be re-created by reinstalling?
If not, what would be the end-user steps to clean up from all this? :)
Thanks,
Chris.
term.log.1.xz
Description: application/xz
term.log.2.xz
Description: application/xz
