On Mon, Feb 19, 2024 at 09:53:20AM +0000, Matthew Vernon wrote: > On 12/01/2024 12:31, Helmut Grohne wrote: > > > For the gzip case, we have the additional question whether we tolerate > > the temporary policy violation for the trixie upgrade or halt the > > /usr-move and retry with a modified dpkg (that could land in trixie, so > > we could complete in forky).
I note that this question fortunately no longer is relevant. The problem there was that when zutils is removed as part of the upgrade, there was no fixed zutils that could help with resolving the situation. Turning this insight upside down means that gzip's maintainer scripts have to help here. That's what I ended up proposing in https://bugs.debian.org/1059534#30 and as likewise for cryptsetup/cryptsetup-nuke-password and isc-dhcp. While none of these has reached unstable yet, no problems are known with this approach beyond being a layer violation: The diverted package now has to support the diverting package in managing its diversions (until trixie is released). > What's the scope of dpkg modification needed here? And is likely the sort of > thing the dpkg maintainers would accept. Were we not already in a bit of a > mire here, it's not clear to me that policy is wrong here (and thus that we > should set it aside). I discussed a possible temporary feature of dpkg with Guillem. We could temporarily (trixie+forky) change the semantics of dpkg (and then revert the change). Whenever dpkg is about to delete a file, it would determine the realpath of the file to be deleted according to the filesystem. This is a noticeable slowdown as deletion is a frequent operation in package upgrades. It would also require reimplementing dpkg-realpath in C (there is a poc). When the realpath of the file to be deleted differs from the looked up filename and is found to be owned by a package in the dpkg database, dpkg would skip the deletion and issue a warning. The warning would serve as a reminder that this changed behaviour should not be relied upon for future upgrades. The reason we discarded this option was timing: Using this approach would have meant that we could only start moving files after the release of trixie. Bumping back this transition seems harder and harder now. I think we are half-way through the conversion (in terms of package count) with a focus on non-trivial situations. Moving back would cause significant breakage at this time. > This continues to make me worry we are not on the path of robust > engineering. But I appreciate I'm in a very small minority in that regard. This was known right from the start of DEP17 when Luca Boccassi proposed "let's just move all the files". We immediately identified that this path was not robust spelling out a significant fraction of problems right from the start. I tried to reconcile consensus repeatedly and there were little objections when I concluded that we'd move forward with this despite its known fragility. Helmut