Comment 1 for bug 1973382

Hi Athos -- this is an interesting one.

Forgive my ignorance, but per Colin's comments in https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/10 "... dpkg-reconfigure is simulating the process of reinstalling a package without actually unpacking its files again" (which aligned with my understanding of dpkg-reconfigure). Surely if it's "simulating [...] reinstalling a package", then:

> dpkg-reconfigure --frontend=noninteractive postgresql-common

should:

> [result] in a call to
>
> deb-systemd-invoke stop 'postgresql.service',

After all, if it's simulating a reinstallation, shouldn't it restart the service? Surely the error is the test suite assuming that it shouldn't? You are certainly correct that:

> A possible solution to the issue would be to introduce the "-r" (or
> --no-stop-on-upgrade) option to dh_installsystemd in Ubuntu's
> postgresql-common d/rules. This should be enough to keep the
> expected (old) behavior in the package maintainer scripts.

(aside: I'd beg people to use the long option and never touch "-r" or "-R" given we wound up having to grep thru maintscripts to find instances of --no-{restart,stop}-{on,after}-upgrade when fixing the debhelper issue -- not to mention they're just more readable)

Still, it seems to me that the assumption that dpkg-reconfigure *won't* restart postgres is incorrect? Then again, if it's already commonly expected behaviour, maintaining it may well be the wisest course. It would mean that upgrades won't restart the service which may not be desirable, although needsrestart may provide a fallback there?

Interested to hear any thoughts you may have on this -- in tinkering with debhelper and dpkg-reconfigure, I'm painfully aware I'm messing with widely used stuff with a long history of assumed quirks!