Comment 18 for bug 1959054

Many thanks to Andreas for the report, and the logs. I suppose it was too much to hope that this went through entirely smoothly, and so it has come to pass! After digging into the logs above, and then dpkg-reconfigure's code it appears that it does the following (see [1] for details):

* Run the package's prerm script (if it exists)
* Run the package's config script (ditto)
* Run the package's postinst script (ditto)

This may seem a little odd; why run the prerm script if you don't intend on removing the package? Presumably because, prior to the change made above, that's where the "stop services" action went if --no-restart-after-upgrade was specified in d/rules. However, as discussed above, that leaves the restart behaviour of a package spread across two distinct versions in the case of an upgrade (because it's actually the *old* version's prerm that runs, followed by the *new* versions's postinst to start them up again). Now, it's the package's preinst script that handles stopping services.

Therefore, if we were being strict, dpkg-reconfigure ought to run just the preinst, config, and postinst scripts, avoiding the prerm entirely. Unfortunately, I suspect that's likely to break anything that relies upon it running the prerm script, so that's probably not a wise idea. I'll propose a change upstream to add preinst to the running order, leaving prerm alone for now, and I'll post a debdiff with a similar change here.

[1]: https://salsa.debian.org/pkg-debconf/debconf/-/blob/master/dpkg-reconfigure#L196-198