Bug 1173997

Summary: rpm: regression in hard link processing
Product: [Fedora] Fedora Reporter: Florian Weimer <fweimer>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: 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:
Description Flags
kphotobymail-0.4.1-11.fc18.noarch.rpm
none
kphotobymail-0.4.1-11.fc18.src.rpm none

Description Florian Weimer 2014-12-14 18:24:52 UTC
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.

Comment 1 Florian Weimer 2014-12-14 18:25:31 UTC
Created attachment 968571 [details]
kphotobymail-0.4.1-11.fc18.src.rpm

Source RPM for completeness

Comment 2 Ľuboš Kardoš 2015-07-02 14:04:41 UTC
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 ***

Comment 3 Florian Weimer 2015-07-02 14:50:19 UTC
(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.

Comment 4 Ľuboš Kardoš 2015-07-02 15:39:00 UTC
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.