Hi Ted, On Tue, Jun 10, 2025 at 06:19:46PM -0100, Theodore Ts'o wrote: > How important is this that we get thes fix into Trixie? I'm not sure > how bad it will be that the diversion isn't going to be cleaned up. > WDYT?
The affected code path is fuse2.postrm. Due to the use of ||, the "remove" argument works as expected. While abort-install, abort-upgrade and failed-upgrade should be relatively rare, upgrade is common and that's what was reported and what is visible in piuparts. Fortunately, we do not only invoke old.postrm upgrade, but also new.postinst configure and that happens to also delete the diversion. The diversion will actually be gone. As it is new.preinst upgrade that installs the diversion, arguably old.postrm upgrade shouldn't be responsible for removing the diversion in the first place. -if test "$1" = remove || test "$1" = upgrade -o "$1" = failed-upgrade - o "$1" = abort-install -o "$1" = abort-upgrade && dpkg --compare-versions "$2" lt 1.47.2~rc1-1~; then +if test "$1" = remove || test "$1" = failed-upgrade -o "$1" = abort-install -o "$1" = abort-upgrade && dpkg --compare-versions "$2" lt 1.47.2~rc1-1~; then Rather than rely on my understanding (that has been proven wrong several times), I also attempted upgrading fuse2fs from trixie to sid. The message readily reproduces and the diversion is gone after upgrading confirming the analysis. The larger problem I see here is that keeping error trains attentive users to ignore issues unless we fix them. TL;DR: I expect that the practical consequences for non-failure cases is fairly limited (to the unpleasant error message). > I have a fix queued in my repo, but it will mean asking the release > time to do an unblock of a key package fairly late in the process. I > actually have a package update queued up to address a number of data > corruption bugs, and it's Murphy's law that this issue was discovered > *just* after I uploaded a package update and sent in a request to the > release time, literally just an hour or two afterwards. :-/ As the unblock is unanswered and the upload is only a day old, I suggest reuploading and sending an updated debdiff to the bug. That way a RM will only have to look once. The equation changes once a RM replied or the upload has aged. I'm also fine with deferring the issue (e.g. to a point release). Helmut
