Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 192638 - portage exits with 0 after a die in pkg_prerm()
Summary: portage exits with 0 after a die in pkg_prerm()
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All All
: High normal with 1 vote (vote)
Assignee: Portage team
Depends on: 192778
  Show dependency tree
Reported: 2007-09-15 23:17 UTC by SpanKY
Modified: 2022-03-26 05:56 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2007-09-15 23:17:55 UTC
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 (default-linux/amd64/2006.1/desktop, gcc-4.2.1, glibc-2.6.1-r0, x86_64)
Comment 1 Zac Medico gentoo-dev 2007-09-16 00:54:17 UTC
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.
Comment 2 SpanKY gentoo-dev 2007-09-16 00:59:53 UTC
i'm not suggesting we halt the process immediately, just that the failure not be suppressed completely
Comment 3 Steve L 2007-09-16 02:19:21 UTC
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.)
Comment 4 SpanKY gentoo-dev 2007-09-16 02:26:03 UTC
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
Comment 5 Steve L 2007-09-16 03:08:06 UTC
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.
Comment 6 Zac Medico gentoo-dev 2007-09-16 06:45:02 UTC
(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.