[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#801065: Documenting how to not fail postinst on service fails to start



On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> * Steve Langasek <vorlon@debian.org> [230212 00:03]:
> > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > reverse-dependencies on the package which expect to interact with the
> > service the package provides, as these packages may themselves do such
> > interaction in the maintainer script, resulting in cascading damage.

> > And the decision for whether there are reverse-dependencies on your package
> > is non-local and asynchronous.

> > Therefore I think it's always wrong for a package's postinst to exit 0 if:

> >  - it ships a service,
> >  - it is a new install or an upgrade on a system where the service was
> >    previously started successfully, and
> >  - the service fails to start in the postinst.

> I have to strongly disagree with this.  Suppose package A ships a
> service, and package B depends on A and requires A's service to be
> running in order for package B to be useful.  If I install A and disable
> its service, and then install B, I would be very disappointed if B's
> postinst script failed and left B in what dpkg considers an unconfigured
> state.

> Succeeding the install and requiring the user to manually run some
> documented configuration steps is _so_ much more user friendly than
> leaving a broken package (from dpkg's POV).  I intentionally disabled A,
> so when I want to use B, I will take the necessary steps.  I would
> expect that attempting to use B without completing the configuration
> would produce a useful error message.

Up until now the conversation has been about the semantics of exit codes for
package A's maintainer script.

You are now arguing that a package *B* is not allowed to fail on install if
the conditions for its full configuration have not been met.

And I absolutely disagree!  Your rationale that it's user-unfriendly to
leave a package in an unconfigured state, if followed to its logical
conclusion, applies to *any* package.  We might as well not care about
postinst exit codes at all!

This is not hyperbolic.  By imposing restrictions on the ability of packages
to raise error conditions, you are forcing the propagation of erroneous
system state up the dependency stack, breaking untold numbers of assumptions
in the reverse-dependencies.  Keeping the error handling *local* and forcing
the admin to correct the error before proceeding is part of what makes
Debian's system robust.

On 'apt dist-upgrade', having a failing maintainer script can be problematic
wrt the package manager's full state.  But there is no such counterargument
wrt robustness for the simple case of an 'apt install foo' failing its
initial configuration because the system preconditions are not met.

> Package relationships and the idea of "properly configured" have gotten
> much more complex (in a relatively small set of packages) since early
> Debian days.  Packages whose configuration has complex requirements
> should be installable without complete configuration and should be
> resilient and provide good user feedback when run before being properly
> set up.

> I also think that such packages are the exception, rather than the rule,
> and they are usually being administered by people capable of dealing
> with postponing the configuration step.

They are also capable of dealing with 'apt -f install'.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: PGP signature


Reply to: