if you stick a die into a pkg_prerm() and then do `emerge pkg ; emerge pkg` (thus forcing pkg_prerm() in the upgrade step), portage's exit status is incorrectly 0 cd /usr/portage emerge -C sandboxshell echo 'pkg_prerm() { die; }' >> app-shells/sandboxshell/sandboxshell-0.3-r4.ebuild emerge sandboxshell emerge sandboxshell echo $? the last emerge will exit 0 Portage 2.1.3.9 (default-linux/amd64/2006.1/desktop, gcc-4.2.1, glibc-2.6.1-r0, 2.6.22.2 x86_64)
That can only happen when the package is replaced with the same exact version of itself. It's a special case inside dblink.treewalk() where it unmerges the installed instance and ignores the return value from that operation. It's an unfortunate place to die because you have both and incomplete install and an incomplete uninstall at the same time.
i'm not suggesting we halt the process immediately, just that the failure not be suppressed completely
I have to agree that it's better to blanket disallow the die in pre_rm() as a matter of technical policy, because of the concern described. Having said that, I don't know what if anything else would cause it to exit in that phase, and I agree the error status is inconsistent with the failure message displayed, and the fact that it doesn't perform the uninstall (which would b0rk any scripts using the program.)
unfortunately, banning die in certain functions would (1) be weird policy wise (you can use die in any function except 1) and (2) prevent me from what i need to do: during an unmerge, run some pre-rm checks and abort the unmerge if the detection indicates doing so would break the system
Yeah good point, didn't think it thru properly, sorry. Hmm i can't see the check applying even if remerging the same version of the same package? I don't see how you'd fix that corner case though, unless the ebuild requests portage do the test via a bash wrapper.
(In reply to comment #2) > i'm not suggesting we halt the process immediately, just that the failure not > be suppressed completely If we halt immediately then will leave one normal vdb entry for the original instance and one -MERGING- vdb entry for the replacement instance. This is similar to the situation that occurs if in dies during preinst, the only differences being which phases have already been executed. I think it's okay for us to halt immediately there as long as we provide sufficient guidance to the user so that they have a clue how to handle it. We should probably provide some way for them to continue the the remaining phases from where it left off.
