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

[Ian Jackson <ian@davenant.greenend.org.uk>]

Ian Jackson writes ("policy: postinst abort-remove state."):
> prerm remove can be called only from "unpacked", "config-failed" and
> "installed".  So Kurt is correct to say that policy is wrong to say
> "it remains installed" since the package might not be installed.
> 
> However, the purpose of running the postinst is to (try to) put the
> package into "installed".  That's what the postinst always does.

Idly thinking about this a day or two ago, it came to me that
obviously we are all approaching this from the wrong angle.

The point of running the postinst is to `put the package back into
installed' as an error-unwinding task, to try to undo what was done
earlier, on the presumption that the package was previously
installed.  The problem occurs when this presumption is not true.

We have missed a possible response to this situation: not run the
postinst at all.  I think this would be much better.

After all the surprise is that the package became installed.
Redefining the postinst's semantics so that the package doesn't count
as installed in this case is the wrong answer - the right answer is
not to attempt to fix up the package in this case.  If it was broken
beforehand then there's no reason why an aborted removal should try to
restore it to fully working state.

Ian.