Hi! On Thu, 2021-10-21 at 13:42:58 +0100, Ian Jackson wrote: > Package: dpkg > Version: 1.16.1 > Control: found -1 1.20.9
> I looked at Policy to double-check my recollection: > > https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade > > | 1. Notify the currently installed package: > | > | a. If a version of the package is already “Installed”, call > | old-prerm upgrade new-version > | > | b. If the script runs but exits with a non-zero exit status, dpkg will > attempt: > | new-prerm failed-upgrade old-version > | If this works, the upgrade continues. If this does not work, [...] > > This seemed to be a bug so I UTSL. I found > > commit 9d3ec0f5a727d439c3cbc8885bcbc78f7a34dd0b > Author: Raphaël Hertzog <hert...@debian.org> > Date: Sat Jun 18 21:36:40 2011 +0200 > > dpkg: do not fallback to "new-prerm failed-upgrade" for downgrades > > If "installed-prerm upgrade" fails, dpkg tries to run "new-prerm > failed-upgrade" so that newer versions of packages can work-around > a bug in the prerm of the installed package. > > In the case of downgrade this logic doesn't make any sense since > the oldest version can't be aware of the bug in the newest version > (that did not exist when the prerm of the oldest version was > written). > > Thus we're disabling the fallback in case of a downgrade or a > reinstallation of the same version. > > and > > dpkg (1.16.1) unstable; urgency=low > ... > > * dpkg: if "prerm upgrade" fails when downgrading, do not try to run > "prerm failed-upgrade" with the prerm of the oldest prerm, it can't > work > around a bug of a newer prerm anyway. > > I do not agree with this change. > > The claim that "it can't work around" is false. It will often be the > case that simply running a prerm without the bug is sufficient and > correct. Thanks! Yeah, I concur. I've actually stumbled over this specific code path in the past, which bothered me and looked odd, but didn't end up digging further as I didn't recall it being a late modification. > Analysis: > > Downgrades are not usual. Higher-level package managers like apt will > not do it by default. And indeed downgrades are not fully supported > by Debian; rather they are available on a best-effort basis. > > Furthermore, this version-number dependent behaviour in maintscript > processing in dpkg is (i) anomalous and (ii) confusing. I don't think > there are other cases where dpkg behaviour so subtly depends on > whether something is thought to be an upgrade or downgrade. > > It seems to me that it is better to enable the fallback in all cases. > That would have helped the users in this case. When it's a downgrade, > things are already going wrong and the user is already knowingly > taking some risks. Most likely, they are a developer trying out > local, experimental or untested packages, or a user who likes to live > on the bleeding edge. > > Having the fallback available even for downgrades will often make it > possible to recover from a broken package simply by reinstalling the > non-broken one (as in this case). ACK, I fully agree. > If you disagree and think the behavioural change should be kept, then > policy ought to be changed. And probably, a message about skipping > the fallback would be helpful - both for un-confusing someone > debugging dpkg, and for the user/developer who is afflicted by a > broken pre-rm: it would tell them what they need to do (a bodge like I > just did). No, I've just reverted this locally and will be included in the next upload. Thanks for the digging and analysis. Regards, Guillem
