FS#8585 - Implement true transaction system in pacman

Attached to Project: Pacman
Opened by Dan McGee (toofishes) - Friday, 09 November 2007, 18:35 GMT
Last edited by Allan McRae (Allan) - Saturday, 04 August 2012, 03:18 GMT
Task Type Feature Request
Category Backend/Core
Status Assigned
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.6
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 17
Private No

Details

Pacman needs a new transaction system that actually allows us to roll back package updates. This will solve a handful of issues we currently have, including several open bugs.

An initial proposal from Aaron:

I'm going to run with the hidden+suffix format here. That is:
/usr/bin/foo
will be extracted as
/usr/bin/.foo.pacman-new-$PID
on any error, it is deleted and all previous extractions are deleted.

Then, we move foo out of the way:
/usr/bin/foo --> /usr/bin/.foo.pacman-old-$PID
any error rolls back. Otherwise, move the new one in place
/usr/bin/.foo.pacman-new-$PID --> /usr/bin/foo
with obvious roll back.

So, in pseudo-code here:

new_files = []
old_files = []

try:
for file in package_files:
new_files += [extract(file.name + "-new-" + pid)]
if exists(file.name):
old_files += [move(file.name, file.name + "-old-" + pid)]
move_all(new_files, files)
except:
move_all(old_files, files)
delete_all(new_files)
else:
delete_all(old_files)


This should be small enough to performance test. Any problems here?
This task depends upon

This task blocks these from closing
FS#3564 - Pacman + Immutable Files
Comment by Aaron Griffin (phrakture) - Friday, 09 November 2007, 18:39 GMT
Go Dan go! Too bad our flyspray install doesn't do indentation properly.... (we'd have to turn on doku syntax)
Comment by Pierre Schmitz (Pierre) - Monday, 27 July 2009, 09:20 GMT
I just found this old task. But as its added to the pacman 4.0 roadmap my input might still be useful. ;-)

I don't think its possible to get a real transaction system from within pacman. The solution posted above might work in some cases but it fails on others or makes it even worse. I really don't know much cases when this will work at all; maybe if the disk runs out of space; but this should be possible to check without extracting anything.

So, but when does this fail? It will fail when pacman crashes or is killed during its operation. This could be due to user intervention, pacman bug or just power loss. Yes, due to the use of mv every single files is safe but not the package or even the whole update with several packages involved.

It will add a lot of overhead during updates/install with more than one package. If you update 1000 packages you have to keep the temporary files to the end after everything is checked. This might easily exceed disk space because in worst case you need more than twice as space as the actual files.

And last but not least the concept of install scripts makes this solution useless.

In the end its just not possible to implement transactions within pacman. Compare it to a database server where its not possible to implement transactions in the client. Only the server can do this.

The only way I can think of how this can be easily done is using filesystem snapshots: create a snapshot -> run pacman -> if anything fails reollback.

Long story short: I don't see any need to implement this in pacman as its not possible anyway.
Comment by Eli Schwartz (eschwartz) - Friday, 04 August 2017, 03:47 GMT
pacman hooks are now a thing, and https://www.archlinux.org/packages/community/any/snap-pac/ makes use of snapper to create filesystem snapshots Pre and PostTransaction. I think this is a pretty reasonable solution. :)
Comment by AMM (amish) - Monday, 26 March 2018, 05:34 GMT
Some discussion related to this:
https://bbs.archlinux.org/viewtopic.php?pid=1775911#p1775911

Loading...