Created attachment 968570 [details]
Description of problem:
Some old RPM packages containing ghost files and hard links can no longer be installed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm -i --nodeps kphotobymail-0.4.1-11.fc18.noarch.rpm
error: unpacking of archive failed on file /usr/lib/python2.7/site-packages/Kphotobymail/EXIF.pyc;548dd43a: cpio: Digest mismatch
error: kphotobymail-0.4.1-11.fc18.noarch: install failed
Package is installed.
-rw-r--r-- 2 root root 0 Jul 20 2012 ./usr/lib/python2.7/site-packages/Kphotobymail/EXIF.pyc
-rw-r--r-- 2 root root 27797 Jul 20 2012 ./usr/lib/python2.7/site-packages/Kphotobymail/EXIF.pyo
Header says (excerpt):
I.e., both files have payload according to the header.
Created attachment 968571 [details]
Source RPM for completeness
The problem is in rpmbuild with which was this package (kphotobymail) built. This was already reported and fixed, so closing as duplicate.
*** This bug has been marked as a duplicate of bug 1156497 ***
(In reply to Ľuboš Kardoš from comment #2)
> The problem is in rpmbuild with which was this package (kphotobymail) built.
> This was already reported and fixed, so closing as duplicate.
Could you please elaborate why the kphotobymail RPM file is broken? As far as I can tell, it follows a valid interpretation of the RPM header semantics, and older RPM versions could install it.
If this is not fixed, this bug will cause problems with constructing build environments with newer RPM versions. It already prevents me from upgrading a host beyond Fedora 20.
It is broken because of inconsistency between the rpm cpio archive and the rpm header. In the header the file EXIF.pyo is marked as a ghost file, that means that it mustn't be in the archive but it is there.
Because EXIF.pyo is in the cpio archive, EXIF.pyc is marked as a hard link to EXIF.pyo in the archive, but is not marked as a hard link in the rpm header because EXIF.pyo is a ghost file.
When rpm tries to install the file EXIF.pyc then it knows from the rpm header that EXIF.pyc is not a hard link so it tries to read its content from the cpio archive but there is no file content because in the archive EXIF.pyc is a hard link (that is how cpio works, only the last hard link has content). So rpm reads some data from the next file but that data doesn't match the expected digest so rpm complains about digest mismatch.
It worked in some previous version of rpm because that version probably ignored meta data from the header and it only read meta data from the cpio archive.