Also ich kann es weiterhin reproduzieren, und auch die --debug Ausgaben zeigen hier wie der Fehler passiert.
Kannst du testweise einfach mal pacman sich selbst aktualisieren lassen? Wie gesagt, es passiert nur wenn pacman upgradet/reinstalliert wird. Nicht bei "normalen" Updates von Paketen. Dem Cache passiert auch nichts, dem System nicht wenn es aktuell ist. Muß halt nur ggf. den Symlink wieder herstellen.
Das ist bei mir die Ausgangssituation:
# LANG=C ls -ld /var/cache/pacman/*
lrwxrwxrwx 1 root root 14 Apr 26 09:48 /var/cache/pacman/pkg -> /mnt/s01/pkg64
# LANG=C stat /var/cache/pacman/pkg
File: /var/cache/pacman/pkg -> /mnt/s01/pkg64
Size: 14 Blocks: 0 IO Block: 4096 symbolic link
Device: 802h/2050d Inode: 9568260 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-04-26 09:48:08.234586255 +0200
Modify: 2017-04-26 09:48:04.111378038 +0200
Change: 2017-04-26 09:48:04.111378038 +0200
Birth: -
Jetzt simuliere ich ein Systemupdate (-Syu) inkl. des pacman-Paketes, indem ich pacman reinstalliere und zusätzlich ein neues Paket installiere. Letzteres, um den Punkt "hinterläßt ein teilaktualisiertes System" zu verdeutlichen.
Beide Pakete (pacman und pastebinit) sind im Cache vorhanden.
# LANG=C pacman -S pacman pastebinit
warning: pacman-5.0.1-5 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (2) pacman-5.0.1-5 pastebinit-1.5-1
Total Installed Size: 4.97 MiB
Net Upgrade Size: 0.55 MiB
:: Proceed with installation? [Y/n] y
(2/2) checking keys in keyring [#############################] 100%
(2/2) checking package integrity [#############################] 100%
(2/2) loading package files [#############################] 100%
(2/2) checking for file conflicts [#############################] 100%
(2/2) checking available disk space [#############################] 100%
:: Processing package changes...
error: cannot remove /var/cache/pacman/pkg/ (Not a directory)
(1/2) reinstalling pacman [#############################] 100%
error: could not open file /var/cache/pacman/pkg/pastebinit-1.5-1-any.pkg.tar.xz: No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
Wie man sieht, nach der Reinstallation des pacman-Paketes war der vormals intakte Cache weg/leer, was die weitere Transaktion (pastebinit) unmöglich macht (= teilaktualisiertes System, z.B. keine post-Hooks, usw).
Beim pastebinit Paket hat mir dieser Abbruch auch "kaputte" Metadaten in /var/lib/pacman/local/pastebinit-blablubb/ hinterlassen, welches ab hier weitere Arbeit mit pacman nicht möglich machen.
error: could not open file /var/lib/pacman/local/pastebinit-1.5-1/desc: No such file or directory
warning: could not fully load metadata for package pastebinit-1.5-1
error: failed to prepare transaction (invalid or corrupted package)
# touch /var/lib/pacman/local/pastebinit-1.5-1/{desc,files}
# pacman -R pastebinit
Ich stelle den Symlink zum Cache wieder her und starte erneut den Lauf mittels --debug Ausgabe:
# rmdir /var/cache/pacman/pkg/
# ln -s /mnt/s01/pkg64 /var/cache/pacman/pkg
# LANG=C pacman --debug -S pacman pastebinit 2>&1 | tee symlink-pacman.log
Das vollständige --debug Log ist hier zu finden:
https://pastebin.com/smnfDDNi
Zwei relevante Stellen in der debug-Ausgabe wo es wohl passiert sehe ich:
...
debug: installing packages
reinstalling pacman...
debug: reinstalling package pacman-5.0.1-5
debug: removing old package first (pacman-5.0.1-5)
debug: removing 349 files
debug: keeping directory /var/lib/pacman/ (contains files)
debug: keeping directory /var/lib/ (contains files)
debug: unlinking /var/cache/pacman/pkg/
error: cannot remove /var/cache/pacman/pkg/ (Not a directory)
debug: keeping directory /var/cache/pacman/ (contains files)
debug: keeping directory /var/cache/ (contains files)
debug: keeping directory /var/ (contains files)
....
Also wird /var/cache/pacman/pk hier entweder schon beim unlinken entfernt, bzw. versucht zu entfernen. Da eben "not an directory", sondern ein (symlink)-File. Der Inhalt wird nicht geprüft wie bei den regulären Dirs.
Letztendlich kritisch wird es dann weiter unten, wo der Inhalt des pacman.pkg.tar.xz neu entpackt wird:
debug: removing entry 'pacman' from 'local' cache
debug: extracting files
debug: opening archive /var/cache/pacman/pkg/pacman-5.0.1-5-x86_64.pkg.tar.xz
...
debug: action: leaving existing file in place (<------ Kommentar: eben nicht!!!)
...
debug: extracting /usr/bin/pacman-db-upgrade
debug: extract: skipping dir extraction of /var/
debug: extract: skipping dir extraction of /var/cache/
debug: extract: skipping dir extraction of /var/lib/
debug: extract: skipping dir extraction of /var/lib/pacman/
debug: extract: skipping dir extraction of /var/cache/pacman/ (<-------- Bis hier OK)
debug: extract: overwriting file with dir /var/cache/pacman/pkg/ (<-------- Sehr bööööse!!!)
debug: extracting /var/cache/pacman/pkg/
debug: updating database
debug: adding database entry 'pacman'
pacman ersetzt nun also /var/cache/pacman/pkg mit dem *Inhalt* aus dem pkg.tar.gz und erzeugt so einen "leeren" Cache. Sieht man auch deutlich am timestamp dieses Cache-Dirs:
# LANG=C ls -ld /var/cache/pacman/*
drwxr-xr-x 2 root root 4096 Feb 11 12:49 /var/cache/pacman/pkg
Feb 11 12:49 ist exakt der Timestamp aus dem pkg.tar.xz
Und das passiert nur mir? Ein Symlink ist aus FS-Sicht immer ein "File", deshalb müßte das Unlinken/Entpacken ("not a dir") doch bei Dir (Euch) auch passieren. Ich könnte mir ad hoc nicht erklären, warum das nur bei mir so stattfinden sollte...
Das Erzeugen von z.B. Verzeichnissen durch einfaches Entpacken aus Archiven ist IMHO zumindest hier ohne weiter Prüfung nicht optimal, und führt bei lediglicher Prüfung von "directory" und "not empty" dann zu diesem Fehler.