Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#5987 - pacman pid in /tmp/pacman.lck... pacmanlib?
Attached to Project:
Pacman
Opened by pajaro (pajaro) - Monday, 11 December 2006, 21:00 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 30 May 2007, 20:00 GMT
Opened by pajaro (pajaro) - Monday, 11 December 2006, 21:00 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 30 May 2007, 20:00 GMT
|
DetailsIt would be very useful to have pacman pid stored inside /tmp/pacman.lck.
This way, when another pacman instance runs, it can check if the process is still running, even if the process is not called pacman (let's say, someone made an alternate package manager). in addition it would be good to store which tasks pacman is performing, so that if it is just performing a search you know that you can install a package at the same time, or that if it is doing a sync a search won't be up to date in a while, or may be corrupted. This would also imply making the pacman.lck multiprocess. Together with this a frontend should be created (let's call it pacmanlib), so that you can do "pacmanlib --add-process $PID $STATE" and "pacmanlib --remove-process $PID". pacmanlib would be the multiinstance manager, so, if you want to do "pacmanlib --add-process $PID SYNC", it returns an error message (it doesn't need to be an output on STDERR) if this operation can't be done in this moment because another processes is performing a conflicting task. pacmanlib could also be responsible of checking if the processes that are listed in /tmp/pacman.lck are still running. pacmanlib would make completely clean the access to the database. ps: I call it pacmanlib because i think it is a good name for pacman library's frontend. |
This task depends upon
Closed by Dan McGee (toofishes)
Wednesday, 30 May 2007, 20:00 GMT
Reason for closing: Won't fix
Additional comments about closing: Not very KISS for the few cases where this would help.
Wednesday, 30 May 2007, 20:00 GMT
Reason for closing: Won't fix
Additional comments about closing: Not very KISS for the few cases where this would help.
Comment by Roman Kyrylych (Romashka) -
Thursday, 14 December 2006, 12:31 GMT
IIRC pacman 3 can do more things in parallel.
Comment by pajaro (pajaro) -
Thursday, 14 December 2006, 12:41 GMT
What does this mean?
Comment by Roman Kyrylych (Romashka) -
Thursday, 14 December 2006, 13:07 GMT
That pacman 3 does implement some extended locking scheme, I suppose.
Comment by Dan McGee (toofishes) -
Wednesday, 30 May 2007, 19:59 GMT
Elaborate request- pacman3 can run certain ops in parallel without problems, so this isn't going to happen anytime soon. Marking as closed as we have fixed the main issue.