On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote: > * 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. 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature