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#53593 - Size check interferes with read-only mounts
Attached to Project:
Pacman
Opened by Alexander Shukaev (A.Shukaev) - Thursday, 06 April 2017, 21:01 GMT
Last edited by Allan McRae (Allan) - Thursday, 06 April 2017, 21:46 GMT
Opened by Alexander Shukaev (A.Shukaev) - Thursday, 06 April 2017, 21:01 GMT
Last edited by Allan McRae (Allan) - Thursday, 06 April 2017, 21:46 GMT
|
DetailsSummary and Info:
Recently started using read-only mount of '/usr'. Had to implement hooks to remount it as read/write before installation and remount it back to read-only after installation of packages. For instance: [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = Package Target = * [Action] Description = Remounting '/usr' read/write... Depends = util-linux When = PreTransaction Exec = '/usr/local/sbin/usr-remount' rw AbortOnFail and [Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = Package Target = * [Action] Description = Remounting '/usr' read-only... Depends = util-linux When = PostTransaction Exec = '/usr/local/sbin/usr-remount' ro Works very well except for CheckSpace in '/etc/pacman.conf'. It always gives an error that there is no space available due to '/usr' still being mounted read-only at this stage. I think 'CheckSpace' should either be reimplemented or (if not possible) a hook with similar functionality should come by default with the 'pacman' package, so that one could still use it by putting it after remount to read/write one. |
This task depends upon
Comment by Alexander Shukaev (A.Shukaev) -
Thursday, 06 April 2017, 23:57 GMT
May I kindly ask for rationale behind this speedy "Won't fix" decision?