autopkgtests failures due to debhelper 13.6 changes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
postgresql-common (Debian) |
Fix Released
|
Unknown
|
|||
postgresql-common (Ubuntu) |
Fix Released
|
Undecided
|
Athos Ribeiro | ||
Jammy |
Fix Committed
|
Undecided
|
Athos Ribeiro |
Bug Description
[ Impact ]
The current postgresql-common DEP8 test suite will fail for any new postgresql-common builds in jammy (even if they are no-change-
This happens because new builds will pick-up different versions of debhelper/debconf than the ones used to build the package shipped in jammy. These new debhelper/debconf versions changed the built package control preinst output to stop the service upon installation.
The proposed fix intends to mimic jammy's postgresql-common behavior even when built with the new debhelper/debconf versions.
[ Test Plan ]
- Rebuild the package (no changes) in a PPA
- Run the DEP8 test suite for that PPA package
- Verify the autopkgtest fails
- Apply the proposed fix
- Verify that tests now pass
Finally, verify that the binary packages control data did not change for the maintscripts to avoid future upgrade unexpected issues (i.e., maintain the package behavior - no control logical changes).
[ Where problems could occur ]
By Verifying that the binary packages control logical data did not change for the maintscripts, we are actually ensuring this SRU suppresses the changes that would be applied to the package by the debhelper/debconf change. Still, there may be other unaccounted dependency changes (as this one was once) that may affect the package usability. If that is the case, we will need to evaluate and deal with possible issues in future SRUs.
[ Other info ]
The reason this issue is only manifesting in jammy now is because our latest postgresql-common build in jammy was performed during jammy's development, before the aforementioned debhelper/debconf changes landed.
When trying to SRU a fix for LP: #2007794, we realized jammy is also affected by this bug.
[ Original message ]
As seen in
https:/
postgresql-common autopkgtest suite have been failing with
# BEGIN LOGS
=== Running test 012_maintscripts.t ... ===
1..14
# We are running systemd
ok 1 - pg_createcluster 14 main --start
ok 2 - postmaster PID is 3634
ok 3 - dpkg-reconfigure --frontend=
head: cannot open '/var/lib/
not ok 4 - postmaster PID is
not ok 5 - postmaster was not restarted
# Failed test 'postmaster PID is '
# at ./t/012_
# Failed test 'postmaster was not restarted'
# at ./t/012_
# got: '3634'
# expected: ''
ok 6 - pg_dropcluster 14 main --stop
# Cleanup
ok 7 - Cleanup: No clusters left behind
ok 8 - No postgres processes left behind
ok 9 - No files in /etc/postgresql left behind
ok 10 - No files in /var/lib/postgresql left behind
ok 11 - No files in /var/run/postgresql left behind
ok 12 - No files in /var/log/postgresql left behind
ok 13 - netstat -avptn 2>/dev/null | grep ":543[2-
ok 14 - PostgreSQL TCP ports are closed
# Looks like you failed 2 tests of 14.
# END LOGS
The test fails because, in Ubuntu, running
dpkg-reconfigure --frontend=
results in a call to
deb-systemd-invoke stop 'postgresql.
stopping the service which the test expects to be up and running (untouched).
This started happening after the following debhelper change introduced in debhelper 13.6:
https:/
Which resulted in the following diff in the postgresql-common preinst script:
# BEGIN DIFF
--- 238-comm/preinst 2022-02-10 07:02:57.000000000 -0300
+++ 241-comm/preinst 2022-05-11 10:57:04.000000000 -0300
@@ -16,7 +16,12 @@
;;
esac
-# Automatically added by dh_installdeb/
+# Automatically added by dh_installdeb/
dpkg-maintscri
# End automatically added section
+# Automatically added by dh_installsyste
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ] ; then
+ deb-systemd-invoke stop 'postgresql.
+fi
+# End automatically added section
# END DIFF
Tests passed in Debian as shown in
https:/
Note that it was using debhelper 13.7.1, which did introduce the new snipped into the preinst script. Local autopkgtest runs for Debian also succeed.
The reason for the test to fail in Ubuntu and pass in Debian lies in
which is applied in Ubuntu delta (but not in Debian).
A possible solution to the issue would be to introduce the "-r" (or --no-stop-
Then, if/once https:/
Related branches
- git-ubuntu bot: Approve
- Bryce Harrington (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 138 lines (+31/-5)5 files modifiedPgCommon.pm (+2/-2)
debian/changelog (+7/-0)
debian/control (+2/-1)
debian/rules (+2/-2)
t/005_PgCommon.t (+18/-0)
- git-ubuntu bot: Approve
- Bryce Harrington (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 58 lines (+17/-3)3 files modifieddebian/changelog (+13/-0)
debian/control (+2/-1)
debian/rules (+2/-2)
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
-
Diff: 44 lines (+10/-3)3 files modifieddebian/changelog (+6/-0)
debian/control (+2/-1)
debian/rules (+2/-2)
Changed in postgresql-common (Ubuntu): | |
status: | New → Triaged |
assignee: | nobody → Athos Ribeiro (athos-ribeiro) |
Changed in postgresql-common (Debian): | |
status: | Unknown → New |
tags: | removed: server-todo |
Changed in postgresql-common (Debian): | |
status: | New → Fix Released |
Changed in postgresql-common (Ubuntu Jammy): | |
assignee: | nobody → Athos Ribeiro (athos-ribeiro) |
description: | updated |
tags: | added: block-proposed-jammy |
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 service' ,
>
> deb-systemd-invoke stop 'postgresql.
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 on-upgrade) option to dh_installsystemd in Ubuntu's
> --no-stop-
> 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!