FS#10262 - Weird issue with full cache
Attached to Project:
Pacman
Opened by Aaron Griffin (phrakture) - Wednesday, 23 April 2008, 19:23 GMT
Last edited by Xavier (shining) - Tuesday, 13 May 2008, 19:57 GMT
Opened by Aaron Griffin (phrakture) - Wednesday, 23 April 2008, 19:23 GMT
Last edited by Xavier (shining) - Tuesday, 13 May 2008, 19:57 GMT
|
Details
I only know of this bug by proxy: Andy experienced it.
pacman -Syu showed devtools 0.6.2 as an upgrade, but it was not upgraded after the -Syu completed. pacman -Syf devtools also reported success but the package was not upgraded. Even removing /var/lib/pacman/local/devtools-0.6-1/ and running -Syf devtools reinstalled the entry for 0.6 It turns out that 0.6 was in the cache, and there wasn't enough space to download 0.6.2, but 0.6 was read and reinstalled from the cache. I have no clue how this could happen... maybe %FILENAME% isn't used right here? |
This task depends upon
Closed by Xavier (shining)
Tuesday, 13 May 2008, 19:57 GMT
Reason for closing: Not a bug
Additional comments about closing: This is not a pacman bug, and Eric fixed the devtools database entry.
Tuesday, 13 May 2008, 19:57 GMT
Reason for closing: Not a bug
Additional comments about closing: This is not a pacman bug, and Eric fixed the devtools database entry.
Also, these kind of issues happened many times in the past.
The directory name in the database, the desc file inside, and the package itself with its .PKGINFO have together several redundant information,
but we never check that they match. So this often leads to confusing situation, very similar to this bug report.
A quick check reveals a first inconsistency here (i686 arch) :
head /var/lib/pacman/sync/extra/devtools-0.6.2-1/desc
%FILENAME%
devtools-0.6-1-x86_64.pkg.tar.gz
Some earlier discussions that might (or might not) be relevant :
http://archlinux.org/pipermail/pacman-dev/2007-November/010335.html
http://archlinux.org/pipermail/pacman-dev/2007-November/010310.html
Of course, if inconsistencies could be avoided in the first place, it would be better and easier :)
I realized something. syncdbs has md5sums! And I think, that we can assume, that /desc etc. is computed correctly from the package file. So all of the entries used by pacman for checkdeps and checkconflicts should be valid, since the md5sum matched. The only wrong information is the package version, which is computed from the directory name of /var/lib/pacman/... This was introduced for efficiency. Maybe we could try to remove this and do some speed tests.