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

[Marvin Renich <mrvn@renich.org>]

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

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.

...Marvin