Bug#443334: policy: postinst abort-remove state.

[Kurt Roeckx <kurt@roeckx.be>]

On Tue, Oct 09, 2007 at 07:22:27PM +0100, Ian Jackson wrote:
> However, the purpose of running the postinst is to (try to) put the
> package into "installed".  That's what the postinst always does.
> 
> If the postinst succeeds, dpkg is entitled to assume that the package
> is now installed properly, even if previously its configuration
> failed.

I've been looking at what the different cases are when postinst is
called.  I think it makes most sense that after a succesful
postinst it should be in installed state, even if it's an error unwind
from a different state.

It's not clearly documented in which states a package ends up after
some failed maintainer scripts.


I've also been looking at policy documents itself about postinst, for
instancce it has:
     Your package should call `install-info' to update the Info `dir' file
     in its `postinst' script when called with a `configure' argument
[...]
     You should remove the entries in the `prerm' script when called with a
     `remove' argument:

It seems to me like it shouldn't only call install-info in the
postinst when called with configure.  It seems alot of package get
things like that wrong, including debhelper (#374467, #442079).


Kurt