Hi Simon,
On Fri, Mar 01, 2024 at 11:50:22AM +0000, 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 if
an answer for unstable differs from an answer for (released) trixie? If
that other approach gets implemented, we can still revert the transition
(before trixie is released) and thus avoid this policy violation to show
up in an actual Debian release.
Helmut
