Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote: > I have proposed a change for glib2.0/experimental at > https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which > implements the "delete the old postrm" approach An equivalent glib2.0 change is now in unstable. Unfortunately, GTK 2 and 3 both have an equivalent issue for their input method modules (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065493, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065494 respectively). I'm proposing to address this in the same way as for glib2.0 with https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/3 and https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/22 respectively (untested, test-builds are in progress). As with glib2.0, I apologise for not having caught this at nmudiff time. gdk-pixbuf and GTK 4 probably have a latent version of the same issue, but have avoided a practical problem during this particular transition by not having any time_t in their ABIs and therefore not needing a rename, so they are presumably not immediately urgent to address. I have not attempted to audit other libraries that have plugins, either inside or outside the GNOME team, for an equivalent problem. smcv
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Mon, Mar 04, 2024 at 04:08:37PM +, Simon McVittie wrote: > Copying context from elsewhere in the thread, Sam Hartman wrote: > > Are there solutions in the space of having glib2.0-0 continue to exist > > as a package depended on by glib2.0-0t64 or depending on the new library > > allowing you to replace the postrm? > > to which I replied: > > If libglib2.0-0 continues to exist, then packages that expect the affected > entry points to have 32-bit time_t will still have their dependencies > satisfied, but then when they call the affected entry points, they will > crash, because their time_t is not the same size as GLib's. So as far > as I can see, this is functionally equivalent to reverting the rename: > to be correct, it would have to be accompanied by versioned Breaks on > every package that calls into the affected entry points. Sorry, yes, because we're transitioning the package name but not the soname. My mistake.
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Copying context from elsewhere in the thread, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?
to which I replied:
If libglib2.0-0 continues to exist, then packages that expect the affected
entry points to have 32-bit time_t will still have their dependencies
satisfied, but then when they call the affected entry points, they will
crash, because their time_t is not the same size as GLib's. So as far
as I can see, this is functionally equivalent to reverting the rename:
to be correct, it would have to be accompanied by versioned Breaks on
every package that calls into the affected entry points.
On Mon, 04 Mar 2024 at 08:46:52 -0700, Sam Hartman wrote:
> > "Matthew" == Matthew Garrett writes:
> Matthew> I would like some further
> Matthew> analysis of Sam's proposal, though - I don't think there's
> Matthew> any advantage in undoing the existing solution, but if it
> Matthew> would work then it's maybe a more straightforward solution
> Matthew> for any similar issues in future?
>
> Unfortunately, I think Simon's response to me is definitive.
> Ultimately if the old package exists, it will continue to satisfy
> dependencies.
> That's exactly what we don't want in the time_t transition.
I think the one thing we could do in this direction would be to mitigate
problems like this one *on architectures unaffected by the transition*
(in this case, 64-bit plus i386) by having this situation:
Package: libglib2.0-0
Architecture: amd64 arm64 i386 s390x (etc.)
Depends: libglib2.0-0t64 (>= ${binary:Version})
Description: empty transitional package
Package: libglib2.0-0t64
Architecture: any
Breaks: libglib2.0-0 (<< ${binary:Version})
Replaces: libglib2.0-0 (<< ${binary:Version})
Description: GLib library
I think this would have made upgrades significantly more smooth on the
non-armel, non-armhf architectures, as well - but perhaps I'm missing an
important reason why the 64-bit time_t transition team have chosen not to
do this (and perhaps it's not even possible).
Nothing we do in this direction would help armel and armhf, so there would
still be a problem here to be solved (and probably we would not have found
out about this particular bug until much, much later, when an armel or
armhf GUI user did the upgrade and encountered the bug).
This is obviously only going to help if "most" architectures are
unaffected by the transition. If our next such transition involves
genuinely breaking ABI on the more widely-used architectures, then I
don't see any way to make it less painful. Perhaps this is a sign that
we should try hard to only have transitions shaped like this one if
there is no alternative.
smcv
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
> "Matthew" == Matthew Garrett writes: Matthew> I agree with the conclusions drawn here, but feel that it's Matthew> possibly worth making a stronger general statement that Matthew> policy should never prevent the implementation of a Matthew> well-considered simple solution. I would like some further Matthew> analysis of Sam's proposal, though - I don't think there's Matthew> any advantage in undoing the existing solution, but if it Matthew> would work then it's maybe a more straightforward solution Matthew> for any similar issues in future? Unfortunately, I think Simon's response to me is definitive. Ultimately if the old package exists, it will continue to satisfy dependencies. That's exactly what we don't want in the time_t transition. I think we might revisit this when we come to a discussion of how our tools could provide us more flexibility to make issues like usrmerge and time_t transition easier in the future.
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
I agree with the conclusions drawn here, but feel that it's possibly worth making a stronger general statement that policy should never prevent the implementation of a well-considered simple solution. I would like some further analysis of Sam's proposal, though - I don't think there's any advantage in undoing the existing solution, but if it would work then it's maybe a more straightforward solution for any similar issues in future?
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote: > I have proposed a change for glib2.0/experimental at > https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which > implements the "delete the old postrm" approach. I've uploaded this to experimental, incorporating feedback from Helmut. (Thank you for your thorough review!) Due to the time required to put each version through build/testing, I am not able to propose a corresponding upload for unstable tonight (and having this version in experimental for at least a few hours is probably not a bad plan in any case). smcv
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Sat, 02 Mar 2024 at 20:19:50 +, Simon McVittie wrote: > I am currently downloading all versions of libglib2.0-0 that have > existed on amd64 as tracked by snapshot.d.o. My plan is to extract their > DEBIAN/postrm, import them into a git branch and go back through the > history that way. https://salsa.debian.org/smcv/glib2.0-control-files has the full history. `git log -p postrm` confirms that the only things the postrm has ever done in versions known to snapshot.d.o are: - deleting gschemas.compiled, which is what we want to avoid here; - deleting giomodule.cache, which is what we want to avoid here; - running ldconfig, which is handled by triggers now So I think removing the postrm is viable. smcv
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
I have proposed a change for glib2.0/experimental at https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which implements the "delete the old postrm" approach. I would appreciate review and comments on whether this is something that would be acceptable to upload to experimental, and/or to cherry-pick to the debian/trixie branch that is currently being used for unstable uploads. I believe it is ready for review, and it includes semi-automated tests for #1065022, which do pass for a test-build; but at the time of writing I am waiting for the systematic testing that is appropriate for a production-quality upload, because it takes a long time (around 1 to 2 hours of sbuild, autopkgtest and piuparts in the case of glib2.0). I hope that I am not wasting reviewers' time by asking for review of only-partially-tested changes. As well as the "delete the old postrm" part, the proposed change also includes an attempt to prevent this situation from happening again, by changing the postrm logic so the cleanup is not done if a future package like libglib2.0-0xyz takes over /usr/lib/*/glib-2.0. Because my upload pipeline is time-consuming and I only get a finite number of attempts in a day, 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. If I do not receive any positive or negative feedback by the time the build finishes, I will probably upload it to DELAYED in an attempt to take myself off the critical path, and I might also prepare a DELAYED upload for unstable. This is an attempt to balance the two competing factors that result in there being no acceptable thing to do in this situation: because this is a critical bug that will eventually become critical-path for a project-wide transition, the expectation is that I must upload a fix as soon as possible, but because maintainer scripts run as root on hundreds of thousands of systems, the expectation is that I must not upload without sufficient testing. So, my intention is to do my best, and then invite other developers to take responsibility for a better, higher-version-numbered upload with different timing if they prefer. On Fri, 01 Mar 2024 at 17:44:57 +, Simon McVittie wrote: > Perhaps giomodules.cache should *also* only be removed > during purge, but fixing that has never been anyone's highest priority. That is also implemented in https://salsa.debian.org/gnome-team/glib/-/merge_requests/32. > On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote: > > I'm not sure anyone of us wants to look into multiple old > > libglib2.0-0.postrm scripts > > If my choice is between spending O(hours) on reading old postrm scripts > or O(days) on NMUing GLib-dependent packages, then I'd prefer to read > the postrm scripts. I can't say that either is something I would look > forward to, but if it's what the project requires from me then it will > have to happen. I am currently downloading all versions of libglib2.0-0 that have existed on amd64 as tracked by snapshot.d.o. My plan is to extract their DEBIAN/postrm, import them into a git branch and go back through the history that way. I am doing this in parallel with building a release candidate for experimental rather than doing this analysis first, because as stated above my release pipeline is very long, and I am optimistically assuming that the code added by debhelper when it replaces the #DEBHELPER# token will not be functionally significant. If that assumption is wrong then I will presumably need to to start again and rethink my approach. smcv
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Fri, 01 Mar 2024 at 13:21:51 +0100, Christoph Berg wrote:
> > Possible solution: other ideas?
>
> Make glib2.0-t64 use a different cache filename?
I'm not happy about the idea of introducing long-term divergence in
the upstream code as a result of a Debian-specific packaging problem;
I think we should be going in the direction of fewer, not more,
"weird Debianisms" that break reasonable upstream assumptions.
If there was a finite time window after which we could revert this, that
would be less bad, but as far as I can see it would be possible to keep
libglib2.0-0 installed for multiple release cycles and then purge it, and
it would have just as much impact whenever it happens to get purged.
On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote:
> For this one (but not gschemas.compiled), I am wondering whether
> installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
> might work. That is a file that is going away and therefore, removal of
> libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
> triggered argument after libglib2.0-0.postrm having done the damage.
>
> Do you agree that this would solve giomodule.cache but not
> gschemas.compiled?
Probably? Sorry, I don't have a sufficiently in-depth understanding of
the finer points of triggers to know whether it is guaranteed that the
trigger would go off after libglib2.0-0.postrm has already run.
(Also, as said elsewhere, sysadmins are allowed to remove/exclude
/usr/share/doc, so I wouldn't want to make that load-bearing.)
> Of course, not solving the other one makes this somewhat theoretical.
Right; the schemas problem is the more serious one anyway. So I don't
think it's necessarily worth spending time on bringing my understanding
of triggers up to a point where I would be able to answer your previous
question.
> > - for gschemas.compiled (shared by all architectures), if the multiarch
> > refcount of the library reaches 0, then the file is deleted during the
> > next postrm purge
>
> Do you happen to remember why gschemas.compiled is being removed in
> purge rather than remove?
I don't remember, as such (it was before my involvement) but thankfully
we have version control to answer questions like this for us. According
to the git history, it was originally removed in remove, but that caused
breakage during upgrades (which run the old postrm and then, eventually,
the new postinst): there was a window of time in which the file did
not exist.
For GIO modules, having a window of breakage is not great but not a
disaster, because "most" GLib programs are at least partially functional
without them. Perhaps giomodules.cache should *also* only be removed
during purge, but fixing that has never been anyone's highest priority.
For GSettings schemas, missing schemas are usually treated as a
programming error (assertion failure and hard crash) which caused more
extensive brokenness:
debian/libglib2.0-0.postrm.in: Only remove the compiled schemas on purge,
not during upgrades. Otherwise we have no schemas available until the new
postinst is run, which leads to applications aborting on missing schemas.
— c8b28bc30b4a5ca7ec7bf643ebaeae88bf21c588, 2012-03-30
> > libglib2.0-0t64 could gain a preinst that deletes
> > /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm
>
> Consider a variant of this. We don't really know how old libglib2.0-0
> is
The postrm was introduced in 2010 and hasn't changed a whole lot (14
commits between the beginning of time and current experimental, according
to git log -p --follow debian/libglib2.0-0t64.postrm in the experimental
packaging).
> and I'm not sure anyone of us wants to look into multiple old
> libglib2.0-0.postrm scripts
We don't support skipping an upgrade, so probably only the one in bookworm
(and Ubuntu 22.04 I suppose) is relevant here?
If my choice is between spending O(hours) on reading old postrm scripts
or O(days) on NMUing GLib-dependent packages, then I'd prefer to read
the postrm scripts. I can't say that either is something I would look
forward to, but if it's what the project requires from me then it will
have to happen.
> Both of my thoughts leave a window of time where users of these caches
> will fail.
Yes, and in the case of GSettings schemas that does seem particularly
high-impact.
> > Possible solution: revert t64 rename for glib2.0
>
> Do you see this as a realistic solution for trixie?
Which is "this"?
If you mean reverting the rename and adding Breaks, then yes, it's a
simple matter of doing an extensive amount of of routine work (rename
back, no-changes-NMU all packages that mention those symbols if necessary
so that they will have a higher version number, and add versioned Breaks).
I can't say that I'm looking forward to that work, particularly if the
project expects me to do all of it personally, but it's routine.
I don't know how it would fit into Ubuntu's schedules and deadlines, but
if the alternative is "most
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Hi Helmut (2024.03.01_14:58:10_+) > For this one (but not gschemas.compiled), I am wondering whether > installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright > might work. That is a file that is going away and therefore, removal of > libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a > triggered argument after libglib2.0-0.postrm having done the damage. One concern I have here: It's possible to configure dpkg to skip installing /usr/share/doc/* with --path-exclude. I don't know what effect that has on such triggers, but I assume they wouldn't be triggered. > While removing the postrm is a policy violation, we also understand its > effects quite well. If we have a choice between having all of unstable > (and later trixie) users crash their user sessions and violate policy, > the pragmatic voice in me wants to say yes. Yeah, agreed on that. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Are there solutions in the space of having glib2.0-0 continue to exist as a package depended on by glib2.0-0t64 or depending on the new library allowing you to replace the postrm? That might create a space in time where glib2.0-0.so does not exist, but we probably have more flexibility there than we do with essential packages.
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Hi Simon,
On Fri, Mar 01, 2024 at 11:50:22AM +, Simon McVittie wrote:
> Background
> ==
Thank you for explaining the details so clearly.
> - for giomodule.cache (per-architecture), the file is simply deleted by
> postrm remove
For this one (but not gschemas.compiled), I am wondering whether
installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
might work. That is a file that is going away and therefore, removal of
libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
triggered argument after libglib2.0-0.postrm having done the damage.
Do you agree that this would solve giomodule.cache but not
gschemas.compiled?
Of course, not solving the other one makes this somewhat theoretical.
Your answer still helps me verify that I correctly understood the
problem.
> - for gschemas.compiled (shared by all architectures), if the multiarch
> refcount of the library reaches 0, then the file is deleted during the
> next postrm purge
Do you happen to remember why gschemas.compiled is being removed in
purge rather than remove? Again an answer to this question does not help
you mitigate the symptoms.
> Possible solution: delete libglib2.0-0.postrm in libglib2.0-0t64.preinst
>
>
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?
Consider a variant of this. We don't really know how old libglib2.0-0
is and I'm not sure anyone of us wants to look into multiple old
libglib2.0-0.postrm scripts. Your removal assumes that it never did
anything important. A lesser assumption would be that it always has been
a shell script. We could insert an invocation of
dpkg-trigger --no-await libglib2.0-0-removal
and have libglib2.0-0t64 declare the matching trigger interest.
Both of my thoughts leave a window of time where users of these caches
will fail. Removing the postrm instead will close this window.
I locally verified that removing a postrm will not make dpkg --verify
unhappy.
> Possible solution: revert t64 rename for glib2.0
>
>
> According to Ubuntu's ABI analysis, glib2.0 only has a small number of
> symbols that refer to time_t:
>
> - g_bookmark_file_get_added
> - g_bookmark_file_get_app_info
> - g_bookmark_file_get_modified
> - g_bookmark_file_get_visited
> - g_bookmark_file_set_added
> - g_bookmark_file_set_app_info
> - g_bookmark_file_set_modified
> - g_bookmark_file_set_visited
> - g_date_set_time_t
>
> This seems like maybe a manageable amount to handle with versioned Breaks?
>
> g_date_set_time_t() is the only one that is not already deprecated, and
> according to codesearch.debian.net, the only one that is widely used.
> Its use of time_t is as an input parameter (not via a pointer), so callers
> will certainly all use the correct ABI after a simple rebuild (binNMU).
>
> The GBookMarkFile stuff is primarily used by the GtkBookmarkManager
> in gtk+2.0 and gtk+3.0, plus ardour (which has a reimplementation of
> GtkBookmarkManager for whatever reason) and a bunch of language bindings.
>
> So perhaps we could transition back from libglib2.0-0t64 to libglib2.0-0,
> and give it a versioned Breaks on older versions of the dependent
> packages, NMU'ing the dependent packages if necessary to ensure that
> we know a version number that is guaranteed to be on the "new" side of
> the line?
>
> After the time-critical part of this transition has happened, one of
> the things on my extensive to-do list is looking into whether we can
> change these functions upstream to give them inline wrappers, so that all
> newly-compiled C/C++ code will call the wrapper and not the underlying
> symbol (for example an inline version of g_bookmark_file_get_added()
> would be implemented in terms of g_bookmark_file_get_added_date_time(),
> which returns a non-time_t-sensitive object). However, this certainly
> won't happen upstream until the GLib 2.82 cycle, which will be too late
> for Ubuntu 24.04; and my to-do list is very long, so I would strongly
> prefer the Debian project not to be blocking on me, personally, having
> time to do this.
Do you see this as a realistic solution for trixie?
> Possible solution: other ideas?
> ===
>
> Perhaps someone in the technical committee or another relevant team has
> a better plan?
While removing the postrm is a policy violation, we also understand its
effects quite well. If we have a choice between having all of unstable
(and later trixie) users crash their user sessions and violate policy,
the pragmatic voice in me wants to say yes.
I understand that the answer is time critical now as most unstable users
(like myself) will run into this problem rather soon. Would you mind
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Re: Simon McVittie
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?
That doesn't sound too bad to me.
> Possible solution: other ideas?
Make glib2.0-t64 use a different cache filename?
> If the solution that is chosen is a Policy violation (like deleting
> the problematic postrm) then I would also like to have clarity that the
> Policy violation is tolerable as a less-bad solution, and therefore will
> not itself be treated as a RC bug in trixie.
I would tend to treat policy as a set of rules that you normally
shouldn't break, but if there's a clear argument why it makes sense in
given case, it would be quite silly to reject that solution just
because of formal reasons.
Christoph
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
Package: tech-ctte
Severity: normal
X-Debbugs-Cc: debian-d...@lists.debian.org, debian-gtk-gn...@lists.debian.org,
vor...@debian.org
I'm requesting advice from the tech-ctte (or anyone else with relevant
knowledge, e.g. the dpkg team or the drivers of the time64 transition)
on how to resolve glib2.0 bug #1065022. This is time-sensitive,
because it is a RC bug (temporarily breaking many applications across
this transition) and will hold up the time64 transition.
Background
==
glib2.0 has two similar patterns where files that are managed by dpkg
are summarized in a non-dpkg-managed file, maintained by triggers and the
library postinst/postrm.
The first of these patterns is GSettings schemas. There is a tool that
loads GSettings schemas in XML format from /usr/share/glib-2.0/schemas
and aggregates them into a single binary blob in a more efficient format,
/usr/share/glib-2.0/schemas/gschemas.compiled. For performance reasons,
applications only load gschemas.compiled: there is no support for loading
the more authorable but less efficient XML files directly.
The second of these patterns is GIO modules, a plugin architecture which
loads .so files from /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules
and summarizes their functionality
in /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules/giomodule.cache.
Applications that want to load plugins parse giomodule.cache, and only
dlopen the plugins that provide the desired functionality (for example
an application that doesn't do any networking will not load plugins that
only implement gio-proxy-resolver).
This is implemented with dpkg file-based triggers: when a package adds
or removes GSettings schemas or GIO modules, it triggers processing by
the libglib2.0-0{,t64} postinst. The implementation has been approximately
the same shape for 10 years, and has worked well until now.
Because dpkg doesn't have an equivalent of RPM %ghost files, the two
generated summary files need to be deleted by the library's postrm.
As of bookworm (and still true in trixie), the implementation is:
- for giomodule.cache (per-architecture), the file is simply deleted by
postrm remove
- for gschemas.compiled (shared by all architectures), if the multiarch
refcount of the library reaches 0, then the file is deleted during the
next postrm purge
The bug
===
When we transition from libglib2.0-0 to libglib2.0-0t64, this involves
the removal of libglib2.0-0. In the postrm of libglib2.0-0, removing
libglib2.0-0:amd64 deletes
/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache, and so on for
all the other architectures.
The result is that until the postinst of libglib2.0-0t64:amd64 is run,
amd64 applications will be unable to load GIO plugins, causing
functionality loss (for example, inability to use https, because the
TLS plugin is not loaded).
Similarly, either during or after the transition from libglib2.0-0
to libglib2.0-0t64, users will want to purge libglib2.0-0. In
the postrm of libglib2.0-0, if there are no multiarch
instances of libglib2.0-0 remaining, purging the package deletes
/usr/share/glib-2.0/schemas/gschemas.compiled. The result is that
applications that want to load GSettings schemas will not find their
required schemas, which is normally treated as a programming error
(incorrect installation) that causes a crash with an assertion failure.
The workaround is: after removal or purging of libglib2.0-0, reinstall
either libglib2.0-0t64 or any package that will trigger libglib2.0-0t64.
On multiarch systems, this must be done for the architecture that matches
the instance of libglib2.0-0 that was removed.
During upgrade, I am unsure what ordering guarantees we have about
the postrm of libglib2.0-0 running before or after the postinst of
libglib2.0-0t64 - perhaps we avoid the giomodule.cache bug in practice,
because the postrm runs before the postinst? But purge can happen at any
later time, so we certainly cannot guarantee that libglib2.0-0t64.postinst
will run after purging libglib2.0-0.
I apologise for not having foreseen this.
Non-solutions
=
I am not interested in solutions that would require a use of a time
machine to change the postrm that was shipped in bookworm: bookworm was
already released, and now we are stuck with it. *After* the time-sensitive
part of this issue has been solved, I plan to look into making the postrm
robust against future transitions similar to this one by adding some way
for the new package to take over responsibility for giomodule.cache and
gschemas.compiled, but for this particular transition it's too late: the
first time at which we could rely on that functionality is trixie -> forky.
I am also not interested in solutions that require design changes in GLib,
for example adding a fallback slow-path that ignores the absence of the
summary files and loads the individual GSettings schemas and GIO modules
directly. This is because upstream would not accept such a change, and it
would introduce significant delta into
