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 +0000, 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
Reply to: