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#38758 - [paccache] paccache does not obey pacman database lock
Attached to Project:
Pacman
Opened by Glen Oakley (goakley) - Saturday, 01 February 2014, 14:56 GMT
Last edited by Allan McRae (Allan) - Tuesday, 11 October 2016, 10:30 GMT
Opened by Glen Oakley (goakley) - Saturday, 01 February 2014, 14:56 GMT
Last edited by Allan McRae (Allan) - Tuesday, 11 October 2016, 10:30 GMT
|
DetailsSummary and Info:
The paccache script does not respect the pacman database lock (located at /var/lib/pacman/db.lck). This allows paccache to remove packages that are currently in the process of being installed, causing broken behaviour in the running instance of pacman. Steps to Reproduce: - Attempt to install or upgrade packages using pacman - During package download or install, run paccache to clear all packages |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 11 October 2016, 10:30 GMT
Reason for closing: Won't fix
Additional comments about closing: the contrib directory has been removed
Tuesday, 11 October 2016, 10:30 GMT
Reason for closing: Won't fix
Additional comments about closing: the contrib directory has been removed
Comment by Dave Reisner (falconindy) -
Saturday, 01 February 2014, 15:49 GMT
I'm going to call this user error. paccache operates on the /var/cache/pacman/pkg by default, but it can operate on any given directory which may or may not be under pacman's purview (not to mention that pacman's cache directory can be changed at will, as well). How do you expect paccache to be able to know that it's operating on a directory which pacman is currently using?
Comment by Allan McRae (Allan) -
Sunday, 02 February 2014, 06:40 GMT
Once FS#23501 is fixed, we can probably do something about this.
Comment by Dave Reisner (falconindy) -
Sunday, 02 February 2014, 13:27 GMT
That would surely depend on *how* 23501 is resolved, because I don't really see this as an issue of granularity.
Comment by Allan McRae (Allan) -
Sunday, 02 February 2014, 13:34 GMT
I agree. But given we have basically ruled out flock() et al, any additional locking looks like it would require dumping more lockfiles about the place. If pacman sticks a lock file in the cache directory, then paccache can detect it.