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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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

Loading...