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#33610 - [paccache] doesn't see old package file if arch has changed
Attached to Project:
Pacman
Opened by Baeyens (berbae) - Monday, 28 January 2013, 13:13 GMT
Last edited by Allan McRae (Allan) - Monday, 28 January 2013, 13:42 GMT
Opened by Baeyens (berbae) - Monday, 28 January 2013, 13:13 GMT
Last edited by Allan McRae (Allan) - Monday, 28 January 2013, 13:42 GMT
|
DetailsThe 'filesystem' package has changed the arch part from 'any' to 'x86_64' or 'i686';
so after the upgrade, there are in pacman cache: filesystem-2012.12-1-any.pkg.tar.xz filesystem-2013.01-1-x86_64.pkg.tar.xz In this case the command 'paccache -d -k1 -vv' doesn't see the '2012.12-1' version as an old version of a currently installed/upgraded package, and so doesn't want to delete the old package file from pacman cache directory. Though this happens rarely, in this case, paccache doesn't operate as expected. |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 28 January 2013, 13:42 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#33455
Monday, 28 January 2013, 13:42 GMT
Reason for closing: Duplicate
Additional comments about closing:
FS#33455.FS#33455, which was a problem with an erroneous version test;here the version test is good, but the different 'arch' part of the name makes paccache to see the two package files as different, rather than an old versus new version.
Is the patch solving
FS#33455also solving that issue with a change of the arch in the package file?I'm not really interested in fixing this. "any" is an architecture and rightfully separate from any other value. It's absurdly rare that a package will change like this.