Bug 497459 - yum "Package does not match intended download" on every Presto reconstructed rpm
yum "Package does not match intended download" on every Presto reconstructed rpm
Product: Fedora
Classification: Fedora
Component: deltarpm (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jonathan Dieter
Fedora Extras Quality Assurance
: 498050 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-04-23 21:55 EDT by Charles R. Anderson
Modified: 2014-01-21 18:09 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-28 12:40:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles R. Anderson 2009-04-23 21:55:59 EDT
Description of problem:

For each and every rpm file that was reconstructed from drpm via the yum-presto plugin, yum balks at the reconstructed rpm in the cache dir and deletes it.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. yum install yum-presto
2. yum update
Actual results:

(121/444): gnome-media-2.26.0-2.fc11.x86_64.rpm             | 338 kB     00:00
http://[mirror]/pub/fedora/linux/development/x86_64/os/Packages/gnome-media-2.26.0-2.fc11.x86_64.rpm: (-1, u'Package does not match intended download')
Trying other mirror.

Expected results:

Yum should accept the presto-generated rpm package, and not delete it.

Additional info:

Before yum deleted a presto-reconstructed rpm file, I managed to save a copy out of /var/cache/yum/rawhide/packages and compared it to a fresh download:

>rpmdiff reconstructed/gnome-media-2.26.0-2.fc11.x86_64.rpm downloaded/gnome-media-2.26.0-2.fc11.x86_64.rpm

>rpm -Kv reconstructed/gnome-media-2.26.0-2.fc11.x86_64.rpm downloaded/gnome-media-2.26.0-2.fc11.x86_64.rpm
    Header SHA1 digest: OK (f30b9bf93b5245a15216c8a22802f20c357900e5)
    MD5 digest: OK (b3cb3a057786afc804d0e27d8febd865)
    Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
    Header SHA1 digest: OK (f30b9bf93b5245a15216c8a22802f20c357900e5)
    V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
    MD5 digest: OK (b3cb3a057786afc804d0e27d8febd865)

So they are functionally identical.  However, the file sizes are different:

>ls -l reconstructed/gnome-media-2.26.0-2.fc11.x86_64.rpm  downloaded/gnome-media-2.26.0-2.fc11.x86_64.rpm 
-rw-r-----. 1 cra cra 346501 2009-04-17 12:54 downloaded/gnome-media-2.26.0-2.fc11.x86_64.rpm
-rw-r-----. 1 cra cra 345397 2009-04-23 21:27 reconstructed/gnome-media-2.26.0-2.fc11.x86_64.rpm
Comment 1 James Antill 2009-04-24 09:47:03 EDT
 Amusingly enough I'd just seen this last night and "fixed" yum-presto to call pkg.verifyLocalPkg() instead of relying on applydelta. It still needs fixing, but there isn't anything the plugin can do about it anymore.
Comment 2 Jonathan Dieter 2009-04-24 11:18:36 EDT
This is not a deltarpm bug or a yum-presto bug, but rather an Infrastructure bug.  The deltarpm was created before the target rpm was gpg signed.  So it does indeed build to a valid rpm with exactly the same data as the downloaded rpm, but without the signature.  Because it's not exactly the same file, yum refuses to use it and redownloads the full (signed) rpm (which is what it should do).

The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms.

Not sure how to reassign to Infrastructure.
Comment 3 Jonathan Dieter 2009-04-28 12:34:36 EDT
*** Bug 498050 has been marked as a duplicate of this bug. ***
Comment 4 Jonathan Dieter 2009-04-28 12:39:18 EDT
According to the Changelog in mash-0.5.3-1.fc11, this has been fixed.  Also, yum-presto-0.4.5-5.fc12 has fixed the related bug where if only one mirror is specified, yum won't redownload the full packages.

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