Re: 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 GLib applications crash" then they would
presumably prefer the route that doesn't have those crashes.
If you mean adding inline shims to the upstream headers so that the
affected symbols never actually get called, then I think it's feasible
for trixie but absolutely not feasible for Ubuntu 24.04, and I cannot
guarantee that it can happen at all (upstream might reject it, or I
might get preempted by other work for the rest of the trixie cycle).
> 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?
That's fine, as long as we're aware that anything that needs to happen
before Ubuntu 24.04's import freeze can either happen before that point
or not at all, with no third option.
I'm sorry that coordination with Ubuntu is imposing deadlines on us for
this, but I didn't have the opportunity to choose the timing or design
of the time64 transition, and I'm just trying to resolve brokenness as
fast as I can within my limited capabilities.
> 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.
In principle yes, although if we have long-term divergence between
Debian and Ubuntu around the name of a package as low down the stack as
libglib2.0-0, then that's probably also not good. If we go that route then
we would probably want one of libglib2.0-0 and libglib2.0-0t64 to be a
transitional package depending on the other one.
On Fri, 01 Mar 2024 at 08:44:24 -0700, 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?
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.
smcv
Reply to: