Bug#443334: policy: postinst abort-remove state.
On Tue, 30 Oct 2007, Ian Jackson wrote:
> 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.
Indeed! I have to say that I wasn't convinced by your refutal of the
change done for #432893 because the diagnosis of the problem was clear...
ending up with an installed package when you tried to remove it and it
wasn't cleanly installed before was definitely wrong.
So reverting the change without proposing an alternative fix doesn't
seemed the right thing to do. Now the situation is a bit clearer IMO.
Will you implement that change ?
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: