Josselin Mouette wrote: > it looks like some of the postinst/prerm snippets lead to broken > packages when an upgrade fails.
Yes, see the other two open bugs about this.. (merged).
> The same could be said for the abort-remove case, but its occurrence is
> very unfrequent. In this case, all commands with a prerm snippet seem
> affected, though.
>
> What is the reason for running the commands only in the "configure"
> case? Is there something I'm missing?
In 2000 I dealt with bug #66673 by adding tests for $1 = configure to
several postinst snippets, with the comment:
* Modified all postinst script fragments to only run when called with
"configure". I looked at the other possibilities, and I don't think any
of the supported stuff should be called if the postist is called for
error unwinds. Closes: #66673
Actually, I didn't modify them *all*. I changed postinst-suid,
postinst-menu, postinst-modules, postinst-emacsen, postinst-xfonts,
postinst-wm, postinst-mime, postinst-info-nosection, and postinst-info.
(But not others like postinst-menu-method or postinst-init). Of those,
I'm not sure if I made the right choice for postinst-emacsen and
postinst-info. For the others my choice still seems ok, since these
scripts do not have prerm scripts that undo their actions on upgrade,
and so do not need to handle error unwind from them. (Although the
complexity of considering that may not be worthwhole, it's not as if
running these actions during error unwind would generally be a problem
either.)
I suspect that in the 7 years since, several debhelper commands have
been added and copied the $1 = configure test without looking at the
full complexity of the situation.
> This is at least the case for the gconf snippets, but it looks this is
> also true for doc-base, gconf, info, sgmlcatalog and xmlcatalog.
xmlcatalog isn't part of debhelper. I think I agree about the others.
Also as mentioned in #442079, prerm "remove" needs to be rolled back
in some cases, and prerms that test for upgrade should also test for
failed-upgrade, and generally try to behave the same as on upgrade.
As noted in #374467, there are also plenty of other cases.
--
see shy jo
signature.asc
Description: Digital signature
