FS#2898 - Using pacman for certain things in parallel

Attached to Project: Pacman
Opened by Leonard Ritter (paniq) - Thursday, 30 June 2005, 18:59 GMT
Last edited by Dan McGee (toofishes) - Thursday, 07 February 2008, 04:44 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version 2.9.8
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

opposed to emerge, pacman does not support being called multiple times at once.

tho, it would be nice if

* searching was enabled in a second/third/etc pacman instance, if the first instance is busy with getting/installing a package
* while the first instance is getting/installing, and a second pacman is called with the -S flag, the command gets queued for the first instance, so it hasnt been entered for nothing

i'm suggesting this because i have been running into these issues numerous times and i dont really see why the actions mentioned above shouldnt be possible.

i can imagine that the second part is rather complex to accomplish, but what about the first part?
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 07 February 2008, 04:44 GMT
Reason for closing:  Won't implement
Additional comments about closing:  This is beyond what pacman is meant to do. There can always be read-only processes accessing the DB (with possible consistency issues during access), but queuing writes between processes just isn't practical.
Comment by Judd Vinet (judd) - Thursday, 30 June 2005, 19:27 GMT
Actually, the first part already works.

If pacman -S is already running and an -Ss instance starts, it can search the databases without conflict.

The second is more complicated. If the first pacman installs a package that conflicts with a package being requested in the second pacman instance, then the second won't know about it until it's too late.
Comment by Leonard Ritter (paniq) - Thursday, 30 June 2005, 20:19 GMT
oops. sorry for wasting your time concerning #1.

for #2, i'd imagine it like this:
- user opens two root consoles #1 and #2
- user starts pacman #1 on console #1 with pacman -S kde
- user starts pacman #2 on console #2 with pacman -S kde
- pacman #2 complains about pacman #1 running and asks if kde should be queued for pacman #1, user answers yes
- pacman #1 finishes kde install and checks the queue (file?) for more jobs. it finds the job issued by #2 and treats it like a regular user command issued to pacman #1. it reacts correctly: "package already installed, proceed with upgrade?"
Comment by Leonard Ritter (paniq) - Thursday, 30 June 2005, 20:21 GMT
oh, all additional options should be passed to #1 as well, such as --noconfirm
Comment by Aaron Griffin (phrakture) - Monday, 27 November 2006, 18:13 GMT
I think the second part is a bit too complex to be worthwhile, as it involves inter-process communication which is always messy. I guess we could always implement the pacman lock file as a fifo and read from it on a SIGUSR1 or something like that... basic workflow would be:

* pacman A starts
* pacman B starts, sees the lock fifo exists, writes it's command line to that file
* pacman B sends a SIGUSR1 to pacmanA
* pacman A handles SIGUSR1 by reading the fifo file, and adjusting what it is doing based on the parameters there, and continues.

Assigning to judd for input. It's my opinion that this is too complex to be added, but some others might want it.
Comment by Roman Kyrylych (Romashka) - Thursday, 22 March 2007, 13:44 GMT
Status in CVS?
Comment by Aaron Griffin (phrakture) - Thursday, 22 March 2007, 15:29 GMT
Hmm, lets leave this open for now.

Doing things in parallel requires us to change the locking mechanism to be cleaner, and I plan to do that in 3.1

Loading...