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 <mjg59@srcf.ucam.org> 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
Reply to: