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

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

Kurt Roeckx says:
> [quoting policy:]
>           If this fails, the package is in a "Failed-Config" state, or else
>           it remains "Installed".
> 
> This remains "Installed" is wrong.  It should remain in the state it
> was before the prerm remove was called.   The abort-remove should undo
> what the prerm remove did, and prerm remove can be called from other
> states than installed.

The language here should IMO read
            If this fails, the package is in a "Failed-Config" state, or else
            it remains (or becomes() "Installed".

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.

If the postinst succeeds, dpkg is entitled to assume that the package
is now installed properly, even if previously its configuration
failed.  Packages whose postinst abort-remove only try to undo what
they do in prerm remove are buggy.

Prior to a very recent change in sid, dpkg has behaved the way
described by my proposed wording.  This change should be reverted and
the policy manual correct as I say above.

(The change was made in response to an IMO erroneous bug report
against dpkg.)

I would appreciate it if the policy maintainers would give priority to
speedy resolution of this issue.

Ian.