FS#76596 - pacman updating itself easily ends up in transaction failures making pacman unusable / pkg symlink
Attached to Project:
Arch Linux
Opened by Marco Munari (mar) - Wednesday, 16 November 2022, 06:37 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 16 November 2022, 06:42 GMT
Opened by Marco Munari (mar) - Wednesday, 16 November 2022, 06:37 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 16 November 2022, 06:42 GMT
|
Details
Description:
if /var/cache/pacman/pkg is a symbolic link, the update of pacman package fails and pacman become unusable Additional info: * package version(s) all version up to at least 6.0.1-5 * config and/or log files etc. any including default [2022-11-16T05:46:25+0100] [PACMAN] Running 'pacman -S pacman' [2022-11-16T05:46:33+0100] [ALPM] transaction started [2022-11-16T05:46:33+0100] [ALPM] transaction failed * link to upstream bug report, if any Steps to reproduce: # mv /var/cache/pacman/pkg /var/cache/pacman/pkg.local # ln -s pkg.local /var/cache/pacman/pkg # pacman -S pacman (I also have a pkg.remote shared FS) * workaround: edit /etc/pacman.conf and add pacman to IgnorePkg IgnorePkg = pacman and update manually preparing a pure pkg directory that is not a symbolic link but this workaround recently shows ** side effect to workaround: if pacman remains outdated, those old versions depending on openssl 1.1 start failing not finding libcrypto.so.1.1 because openssl specific version dependency was not in pacman package metadata so openssl updated without noticing that was breaking a dependency of pacman Note a part: users have to take extreme care to handle `pacman` and `linux` _special_ packages, I think some of this care should be moved into pacman and ALPM itself. |
This task depends upon
Closed by Toolybird (Toolybird)
Wednesday, 16 November 2022, 06:42 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#72228
amongst others
Wednesday, 16 November 2022, 06:42 GMT
Reason for closing: Duplicate
Additional comments about closing: