FS#17886 - Pacman's pre_upgrade/install scripts does not stop 'upgrading/installing' after an error

Attached to Project: Pacman
Opened by Anton Prins (aprins) - Monday, 18 January 2010, 08:25 GMT
Last edited by Allan McRae (Allan) - Sunday, 31 January 2016, 04:29 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Pacman's pre_upgrade/install scripts does not stop 'upgrading/installing' after an error.
With a return value <> 0, you can trigger an error message, but pacman just goes further...

I would like to have a 'freespace' check in my pre_upgrade scriptlet and if not enough space, pacman must stop.

Additional info:
* package version(s)
3.2.2 i'm currently using, but saw code in version 3.3.3 does the same thing.

* config and/or log files etc.

Steps to reproduce:

have in a PKGBUILD the section;

pre_upgrade() {
return 1
}
This task depends upon

Closed by  Allan McRae (Allan)
Sunday, 31 January 2016, 04:29 GMT
Reason for closing:  Implemented
Additional comments about closing:  Can be handled with a PreTransaction hook.
Comment by Allan McRae (Allan) - Tuesday, 19 January 2010, 12:09 GMT
Stopping in the middle of an update could leave your system in an unusable state...
Comment by Nagy Gabor (combo) - Tuesday, 19 January 2010, 15:11 GMT
Related task:  FS#9321 
Comment by Anton Prins (aprins) - Tuesday, 19 January 2010, 23:31 GMT
Hi Nagy Gabor/Allen McRae,

Correct, its about the same, the scriptlet function return value as in  FS#9321 

Further Allan, sure it could be strange te stop in the middle, but what i mention is not 'in the middle'.
its in the pre_xxxx functions... so if my own scripts detects a problem i want to abort pacman's upgrade.
(before pacman overwrites binaries)...


Comment by Allan McRae (Allan) - Tuesday, 19 January 2010, 23:58 GMT
pre_upgrade is run prior to the individual package being upgraded, not the whole transaction. So pacman could have upgraded some packages before it gets to the one with failing pre_upgrade and stopping.
Comment by Anton Prins (aprins) - Wednesday, 20 January 2010, 22:21 GMT
Ok clear, if you have more dependencies it could be a problem.

But i have seen file-conflicts could also 'abort' installations (of the current package).
I just wonder how we can handle this without problems!
Comment by Nagy Gabor (combo) - Wednesday, 20 January 2010, 23:29 GMT
I just repeat my comment from  FS#9321 :

"Fortunately, we sort the packages by deps..."

So broken dependencies should not be an issue (unless we have a dependency cycle), but partial upgrade is not recommended in general.
Comment by Allan McRae (Allan) - Saturday, 04 August 2012, 03:43 GMT
Sorting dependencies is not enough to ensure your system does not break.

e.g. libarchive has a soname bump, so pacman is rebuilt against it. Update your system, libarchive gets installed then some install script returns non-zero and pacman aborts before it is upgraded. Now pacman is broken...
Comment by Chris Clark (clark800) - Wednesday, 18 December 2013, 20:50 GMT
I want this feature too. I understand Allan's concern, but if a package aborts in pre_install, it is probably because something went terribly wrong and the system would be screwed up if the install proceeded. This is especially true if the package does a lot of system configuration like editing files in /etc. So ignoring the abort sign is kind of a risk too.

Here is an idea: Whenever pacman detects that a transaction cannot be reduced to a sequence of single-package transactions, it creates an aufs sandbox, installs everything in the transaction into the sandbox, and then merges the sandbox into the root filesystem if nothing failed. If anything failed, then the sandbox is discarded and the system remains unchanged.

In normal situations, the aufs sandbox step would be unnecessary, so there would be no significant performance degradation. Just for special cases like the libarchive/pacman example above the aufs sandbox would be used.
Comment by Dave Reisner (falconindy) - Wednesday, 18 December 2013, 20:54 GMT
Are you seriously suggesting that pacman rely on linux-specific out of tree kernel patches?
Comment by Chris Clark (clark800) - Wednesday, 18 December 2013, 21:07 GMT
It was a serious suggestion, but I didn't realize that it was out of tree. I agree that it should wait until the kernel supports a union filesystem unpatched.
Comment by Chris Clark (clark800) - Tuesday, 11 February 2014, 03:04 GMT
I just saw on Hacker News that there is a new tool called mbox that uses seccomp/BPF to provide a layered sandbox filesystem (http://pdos.csail.mit.edu/mbox/). It looks like this should work for kernel 3.5 and up. The sandboxing idea I mentioned above could be added in such a way that it reverts to the current behavior for kernels that don't support seccomp/BPF.

Loading...