Pacman refuses to delete corrupted package, because it is corrupted...
I had this issue today with two packages (icu-4.4-2-x86_64.pkg.tar.xz and ttf-bitstream-vera-1.10-7-any.pkg.tar.xz). Got asked "<X> is corrupted. Do you want to delete it? [Y/n]" and then told "failed to commit transaction - <x> is invalid or corrupted". Some nice person should add in "Troubleshooting" that in this case one can delete said package manually as root in /var/cache/pacman/pkg. -- Misc 20:17, 17 April 2010 (EDT)
- I'm glad someone asked this. And thanks for the pointer. One of the most annoying things that I've found users have ever had to deal with in the last couple decades has been this sort of problem with automated package management methods, regardless of the OS used. I have noticed, however, that the download process usually weeds out the corrupted downloads before committing them to the install process. It might be that dumping a bad package might be something that is automated by the pacman routine in a better manner than it does now, but downloading again, and overwriting the bad one, should fix the problem without further effort. - KitchM 23:01, 18 April 2010 (EDT)
Troubleshooting: manually reinstall pacman
- I might have been an issue with IIRC pacman 3.4, but I don't think this is happening with pacman 4.
- Closing. -- Karol (talk) 12:04, 30 May 2013 (UTC)
I needed to know what pacman is doing with versions like 1.2.fb9 and 1.2.fb10. The documentation was not clear on that.
Short: I found fb9 is really less than fb10.
It took me a while to find, so I place the links here: version.c source and alpm_pkg_vercmp description. This is what is used. It tries to split the version in only-numeric and only-alpha parts. --JonnyJD 13:58, 1 March 2012 (EST)