* Steve Langasek <vor...@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