Bug#801065: service failures should not fail dpkg installation: https://lists.debian.org/debian-devel/2015/09/msg00532.html
Holger Levsen <[email protected]> Mon, 1 Jun 2026 19:08:54 +0000
| Newsgroups | gmane.linux.debian.devel.policy |
|---|---|
| Message-ID | <ah3YxtjECs2je2UB__3375.10677506856$1780341086$gmane$org@layer-acht.org> |
--C+ov/8ly0l+LVbUf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi serafi, On Fri, May 29, 2026 at 10:50:10PM +0200, Serafeim (Serafi) Zanikolas wrote: > devref guidance, section 6.9.4. "Specific types of packages" has some rec= ently > added guidance but is agnostic as to whether postinst should fail: if the postinst of a package fails, this is usually considered an RC bug, u= sually detect by piuparts.d.o. =20 > my reading of the bug log is that the guidance needs to be nuanced. here'= s an > attempt to reconcile the various views in the discussion: >=20 > Package maintainers are expected to apply judgment with regards to which > postinst behavior is more appropriate to any given package. Here is some > generic guidance: >=20 > 1. a service failing to start upon a fresh install should, in general, > fail postinst, if > 1.1 the service configuration is straightforward and can be reasonably > expected to work as-is in typical Debian setups > 1.2 the service has no external dependencies (e.g. a database which > may be not configured yet, or unreachable at the time of the > install) >=20 > 2. a service failing to restart upon an upgrade should, in general, fail > postinst if > 2.1 postinst can verify with high confidence that the service was > running prior to the restart (which may not always be feasible) > 2.2 the service has no external dependencies or postinst can verify > that they are functional > 2.3 the service configuration has not changed in backwards > incompatible ways between the old and new package versions >=20 > fwiw I wonder whether this would be of much use. "typical Debian setups" = is > ambiguous. verifying whether a remote service is unreachable is not always > straightforward. "backwards incompatible" is not always black and white. I think this is still useful, despite its not all black and white, maybe especially because its not black and white. --=20 cheers, Holger =E2=A2=80=E2=A3=B4=E2=A0=BE=E2=A0=BB=E2=A2=B6=E2=A3=A6=E2=A0=80 =E2=A3=BE=E2=A0=81=E2=A2=A0=E2=A0=92=E2=A0=80=E2=A3=BF=E2=A1=81 holger@(d= ebian|reproducible-builds|layer-acht).org =E2=A2=BF=E2=A1=84=E2=A0=98=E2=A0=B7=E2=A0=9A=E2=A0=8B=E2=A0=80 OpenPGP: = B8BF54137B09D35CF026FE9D 091AB856069AAA1C =E2=A0=88=E2=A0=B3=E2=A3=84 Die Deutschen werden den Gr=C3=BCnen die Klimakatastrophe nie verzeihen. (@= sixtus) --C+ov/8ly0l+LVbUf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmod2MEACgkQCRq4Vgaa qhx21BAAgnsMktr6lgULijUV/fypLv0JPiGXqGX/aIFn1qB3/eha5ixIBg+I182L WFVxzjH7z2igFQ2H0fM0q/988ls6GJ6IiX4jSP0O1dYyBboZ97cMIYkeB5EFDAul zR8L4T7RYZteicDigYB46xPW9JxhHgjGnD91ALTBDX5kdAHWaXPAlbGNEcWTt3aC LtUBx72wgCV9njHbOvvn7SOUpATLCNyxfZ/ovHqnfeabzlGnF7ajt8bQWkZQOkBx euWj6pN6c4U6+j2PvMdGZ35yf83sPH7WCJWil3mnSRrXcVQJvWqtSfFhb0U4Tz0v WNGem5bHYBIezdpLxROobvB13Ug9s725yn5MhSGLPlRL4AeKc/ZfqUBgVqUJWSRl 3kU6fQSBVze9/nruVYp+XvtGF+tszZt8NYSa0yMsQXygwsojSKbKMLMY6PiRX6eI Z7iIDqge8Gxuh3Kvyi6Q362Etl4mAHmaMUBuHHj+7RcPyQfQUZTeWmvAyPb60668 cD5L3hH8G2DGLTpcqjgiDOzEuFe18D23d/SB89Ue2Jdn0Ia0a2u3RXkhWkrnzHV4 8ytciWioW9RI4tTCmj1JOXVrQVDwJtMmF1C3qM3me4HAn7s0UbqCRYk6xVCovy4H E3bNc0a+BImAxXr0ytOeoThtvXnbXvRGLu6439h6qzlrTaEEO2Y= =qo6F -----END PGP SIGNATURE----- --C+ov/8ly0l+LVbUf--