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
