Bug 1173997
Summary: | rpm: regression in hard link processing | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Florian Weimer <fweimer> | ||||||
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 21 | CC: | jzeleny, lkardos, novyjindrich, packaging-team-maint, rvokal | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-07-02 14:04:41 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Created attachment 968571 [details]
kphotobymail-0.4.1-11.fc18.src.rpm
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. |
Created attachment 968570 [details] kphotobymail-0.4.1-11.fc18.noarch.rpm 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): rpm-4.12.0.1-3.fc21.x86_64 How reproducible: Always. Steps to Reproduce: 1. rpm -i --nodeps kphotobymail-0.4.1-11.fc18.noarch.rpm Actual results: 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 Expected results: Package is installed. Payload contains: -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): HEADER:FILEDIGESTS (STRING_ARRAY): 0: "c8cd41ed45d70d95b3738d77fc38ae65f897907983b618f304437fe980f41517" 1: "4191110fbcb84526591bf373a823ddfddf63d52b2645092b063ac7c720345a68" 2: "" 3: "9f3d63a32eb02e39f79f0f4cc79f208ac7df822cd908864d9b01abb9fbaacacb" 4: "73802fe6bef390a277d2f965079f5823667b76de633d4838dc35a04832e5dc63" 5: "73802fe6bef390a277d2f965079f5823667b76de633d4838dc35a04832e5dc63" HEADER:BASENAMES (STRING_ARRAY): 0: "kphotobymail.data" 1: "kphotobymail" 2: "Kphotobymail" 3: "EXIF.py" 4: "EXIF.pyc" 5: "EXIF.pyo" I.e., both files have payload according to the header.