FS#9694 - Universal transaction

Attached to Project: Pacman
Opened by Nagy Gabor (combo) - Tuesday, 26 February 2008, 16:10 GMT
Last edited by Allan McRae (Allan) - Tuesday, 29 December 2020, 13:23 GMT
Task Type Feature Request
Category Backend/Core
Status Assigned
Assigned To Andrew Gregory (andrewgregory)
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No

Details

I mentioned this several times on ML, this task is a reminder and a place to discuss it.

So briefly, it would be nice if user could do the following in ONE command (== in one transaction):
* select some packages to install (-A/U)
* select some packages to remove (-R)
* select some packages to sync (-S)
* apply dependency/conflict resolving and replaces checking on request

Note: the current -S can already do all of these (except  FS#9088 ), so this is mainly a code refactoring request.

+ automatically  FS#9088 ,  FS#5798  and  FS#3492 
+ currently manual replaces is quite hackish: '-Rd foo then -U/S bar' is dangerous; '-S/U var then -R foo' doesn't work always (foo and bar doesn't conflict, but fileconflict) and isn't intuitive at all; doing this cleanly in one transaction is nice
+ we could focus to one transaction instead of three type of them (and the hard-to-follow transaction branch in case of sync)
- getopt() limitation
This task depends upon

Comment by Nagy Gabor (combo) - Tuesday, 26 February 2008, 16:12 GMT
Ref.: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009474.html
Comment by Dan McGee (toofishes) - Tuesday, 26 February 2008, 17:27 GMT
Isn't this similar to FS#8585?
Comment by Nagy Gabor (combo) - Wednesday, 27 February 2008, 07:50 GMT
Imho FS#8585 is a feature request for a new transaction behavior (rollback capability); which seems to be independent from the number of transactions (you can implement rollback to all current transaction types: upgrade/add, remove and sync -- and you can implement universal transaction without rollback capability).

But both FR needs transaction refactoring indeed, and we should keep both request in mind (if we want to implement both) to avoid needless work.
(IMHO 1. implementing universal transaction, 2. add rollback to universal transaction order is easier.)
Comment by Xilon (Xilon) - Monday, 22 December 2008, 11:38 GMT
I think this should definitely be implemented, not necessarily in pacman, but in libalpm. Currently you must specify what type of transaction to initialise. Instead it should be possible to add targets for sync, installation from a file (maybe these could be merged since pmpkg_t has the info) and removal. e.g. based on the current API:

alpm_trans_init(flags, event_cb, conv_cb, progress_cb);
alpm_trans_add_sync_target(some_pkg);
alpm_trans_add_remove_target(another_pkg);
alpm_trans_commit();

I'm not sure in which order these should be applied though, either as defined (defining a new struct with meta info about the operation and adding to a list), or doing removal first, then syncs.
Comment by Aaron Griffin (phrakture) - Tuesday, 23 December 2008, 23:16 GMT
This does make a lot of sense for GUI clients too. If you envision, say, a checklist of packages, with installed ones checked, I could see a user checking 3 new packages, unchecking another, and clicking "submit" or something.

Loading...