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#51377 - [libalpm] inaccurate messaging when replacing symlink with dir
Attached to Project:
Pacman
Opened by Dave Reisner (falconindy) - Friday, 14 October 2016, 12:01 GMT
Last edited by Allan McRae (Allan) - Monday, 17 April 2017, 00:56 GMT
Opened by Dave Reisner (falconindy) - Friday, 14 October 2016, 12:01 GMT
Last edited by Allan McRae (Allan) - Monday, 17 April 2017, 00:56 GMT
|
DetailsSince bb5e6c3b767e923, replacing a symlink with a directory leads to bad messaging on package upgrade. In my case, it's simple enough to reproduce with:
# rm -d /var/cache/pacman/pkg # ln -s /pkg/bin /var/cache/pacman/pkg # pacman -U pacman-git... This results in: :: Processing package changes... error: cannot remove /var/cache/pacman/pkg/ (Not a directory) (1/1) reinstalling pacman-git However, libarchive then proceeds to unlink my /var/cache/pacman/pkg symlink, and replace it with the directory from the pacman-git tarball. |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 17 April 2017, 00:56 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 16b91f79
Monday, 17 April 2017, 00:56 GMT
Reason for closing: Fixed
Additional comments about closing: git commit 16b91f79
1. Do we actually care about the misleading message given that it only occurs because the FS doesn't match the database, which we don't support?
2. How should we actually handle FS/database mismatches on removal? Remove anyway or bail out?
3. If I'm not mistaken, replacing that symlink would have broken any subsequent packages being installed; should we be saving an fd for cache dirs and using openat?