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--