Bug 1173997 - rpm: regression in hard link processing
Summary: rpm: regression in hard link processing
Status: CLOSED DUPLICATE of bug 1156497
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-14 18:24 UTC by Florian Weimer
Modified: 2015-07-02 15:39 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-07-02 14:04:41 UTC


Attachments (Terms of Use)
kphotobymail-0.4.1-11.fc18.noarch.rpm (65.68 KB, application/octet-stream)
2014-12-14 18:24 UTC, Florian Weimer
no flags Details
kphotobymail-0.4.1-11.fc18.src.rpm (49.58 KB, application/octet-stream)
2014-12-14 18:25 UTC, Florian Weimer
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.