FS#9321 - package removal should fail when pre_remove fails

Attached to Project: Pacman
Opened by Antoine Martin (antoinemartin) - Wednesday, 23 January 2008, 20:55 GMT
Last edited by Allan McRae (Allan) - Sunday, 31 January 2016, 04:55 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.1.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

package removal should fail when pre_remove in install file fails

Steps to Reproduce:

Within a package with an install file, make the pre_remove method fail (return a value other than 0). The package removal continues.

IMHO, the package removal should stop at this point. In lib/libalpm/remove.c line 289, some action should be taken if the call to _alpm_runscriptlet returns something different from 0.

Thank you in advance.
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 31 January 2016, 04:55 GMT
Reason for closing:  Implemented
Additional comments about closing:  Use a PreTransaction hook
Comment by Aaron Griffin (phrakture) - Wednesday, 23 January 2008, 21:29 GMT
Man, I could have sworn this was a duplicate as I had the exact same complaint ages ago. Turns out it is NOT a dupe... huh
Comment by Roman Kyrylych (Romashka) - Sunday, 27 January 2008, 22:12 GMT
.install scriptlets in initscripts-splash and virtualbox-ose packages have "press Ctrl-C to abort pacman" in pre_remove because of this.
Comment by Nagy Gabor (combo) - Sunday, 27 January 2008, 23:01 GMT
There is a problem with this: this request is quite a "transaction breaker". If you remove more packages, checkdeps and all other stuffs assumes that the whole transaction will be committed or no packages will be removed.
Fortunately, we sort the packages by deps (so the packages will be removed _before_ its dependencies), but in case of dependency cycle this still can cause problems (database inconsistency) until we have no transaction-rollback implemented.

And the same true for pressing ctrl-c in the middle of a transaction, I suggest not to do that (that is more dangerous, it blindly trust in our "event" handling)
Comment by Roman Kyrylych (Romashka) - Monday, 28 January 2008, 10:02 GMT
Sure, it's a bad way, but it is really needed for those 2 packages as a last chance for user to stop dangerous operation or do some preparations before it will happen, and that's the only way to do this now.
failing on pre_remove returning 0 seems better to me than Ctrl-C.
Comment by Nagy Gabor (combo) - Monday, 28 January 2008, 12:42 GMT
Maybe I wasn't clear in my previous comment:
Basically, I like the idea, I also suggested doing this here: http://www.archlinux.org/pipermail/pacman-dev/2007-August/009127.html

IMHO this is quite easy to implement now, but in my head this depends on FS#8585 (and an other good reasoning for that).
But if you can convince us why implementing this is less dangerous than the current situation, we may give it a try ;-)

Comment by Allan McRae (Allan) - Saturday, 04 August 2012, 03:26 GMT
Given an upgrade is remove then install, what do we do if pre_remove fails on a package in the middle of an upgrade operation?
Comment by Allan McRae (Allan) - Saturday, 09 February 2013, 05:33 GMT
The more I think about this, the more I think it is a bad idea. Aborting in the middle of a transaction is the worst thing that can be done!
Comment by Antoine Martin (antoinemartin) - Saturday, 02 March 2013, 09:28 GMT
I think there may be two solutions, for this :

1) Run the pre_remove of all packages that are marked for removal before actually remove any package and fail if one of them fails. This is what happens for files already present in the filesystem before installation.
2) Emit a warning to the user and ask him what to do : 1) remove anyway 2) don't remove 3) abort transaction ( (1) being default for --noconfirm)
Comment by Allan McRae (Allan) - Sunday, 31 January 2016, 04:55 GMT
This can be done with a hook now.

Loading...