Bug 479869 - Support packages upgrading to different %filedigestalgo
Support packages upgrading to different %filedigestalgo
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-sha2 477043 479990 479995
  Show dependency treegraph
 
Reported: 2009-01-13 12:28 EST by Miloslav Trmač
Modified: 2010-01-26 02:47 EST (History)
6 users (show)

See Also:
Fixed In Version: 4.6.0-1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-24 15:52:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
spec files for test rpms (970 bytes, application/octet-stream)
2009-01-26 13:26 EST, Miloslav Trmač
no flags Details
Don't throw away user's modified config files on cross-hash upgrades (728 bytes, patch)
2009-01-26 13:48 EST, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description Miloslav Trmač 2009-01-13 12:28:50 EST
RPM currently supports SHA-2 in RPMTAG_FILEDIGESTS, but it doesn't handle
packages that change digest algorithm (e.g. on upgrades) correctly.

(I'm not an expert at RPM code.  Please correct me if I'm wrong.)

There are three places where RPM compares file digests from different packages:
- handleInstInstalledFiles
- handleOverlappedFiles
- rpmfiDecideFate

In all three cases at least one of the digests comes from a complete RPM package, so it should be possible to unpack the payload of the package and compute digests of "the other" type for all files in the package.
Comment 1 Miloslav Trmač 2009-01-13 12:50:28 EST
(Fedora 9 and 10 updates will be necessary to support preupgrade to F11.)
Comment 2 Jeff Johnson 2009-01-17 14:59:49 EST
Different digests cannot be computed from payload content "on-the-fly" unless
    1) payloads are unpacked earlier
    2) file resolutions are computed later
either of which is a profound design change to rpmlib.

Have fun!
Comment 3 Miloslav Trmač 2009-01-26 13:26:47 EST
Created attachment 330017 [details]
spec files for test rpms

Attached are specs for test RPMs.  s,/home/mitr/ht,your_test_directory,g, and build all using the default settings (md5), and build all but *1.spec with "--define '_binary_filedigest_algorithm 8'" as well.

Setting up testing environment
==============================
ht=/home/mitr/ht # or your own
mkdir -p $ht/rpmdb
cd $ht
myrpm() { rpm --dbpath $ht/rpmdb "$@"; }
myrpm --initdb

Testing %config handling (rpmfiDecideFate)
==========================================
# %files of ht_config* contain:
#   %config(noreplace) config_file
#   %config config_replace
for action in (do nothing, change config_*), new in (changed,same) do:
    myrpm -ivh ht_config-1-1.noarch.rpm
    # $action
    myrpm -Uvh ht_config-2$new-1.noarch.rpm
    ll $ht/config_*
    myrpm -ev ht_config

results when all packages use md5:
    (do nothing, changed): files changed
    (do nothing, same): file dates changed
    (change files, changed): creates config_file.rpmnew, config_replace.rpmsave;
                             on erase creates config_file.rpmsave
    (change files, same): changes kept on disk;
                          on erase .rpmsave created for both files
results when *1 uses md5, *2* uses sha2:
    (do nothing, changed): files changed
    (do nothing, same): file dates changed
    (change files, changed): files overwritten, old data lost!
    (change files, same): files overwritten, old data lost!
results when *1 uses md5, *2* uses sha2, after applying rpm-4.6.0-rc3-config-hashes.patch:
    (do nothing, changed): files changed
    (do nothing, same): file dates changed
    (change files, changed): creates config_file.rpmnew, config_replace.rpmsave;
                             on erase creates config_file.rpmsave
    (change files, same): config_file change kept on disk (creates .rpmnew),
    	    	  	  config_replace overwritten (creates .rpmsave)
			  on erase creates config_file.rpmsave

Testing file conflict handling (handleInstInstalledFiles, handleOverlappedFiles):
================================================================================
for kind in (same,different), action in (together,separately):
    other=ht_conflict$(kind==same ? 1a : 2)-1-1
    if action==together:
        myrpm -ivh ht_conflict1-1-1.noarch.rpm $other.noarch.rpm
    else:
        myrpm -ivh ht_conflict1-1-1.noarch.rpm
        myrpm -ivh $other.noarch.rpm
    myrpm -ev ht_conflict1 $other
results when all packages use md5:
    (same,together): installs OK
    (same,separately): installs OK
    (different,together): conflict message, nothing installed
    (different,separately): conflict message, $other not installed
Results when *1.* uses md5, $other uses sha2:
    (same,together): conflict message, nothing installed
    (same,separately): conflict message, $other not installed
    (different,together): conflict message, nothing installed
    (different,separately): conflict message, $other not installed
Comment 4 Miloslav Trmač 2009-01-26 13:48:05 EST
Created attachment 330021 [details]
Don't throw away user's modified config files on cross-hash upgrades

Given the above tests, it might be practical not to recompute the hashes.  To summarize the changes between all-md5 and mixed environments:

* If %config files are updated, current rpm will always overwrite with the new
  version, discarding any local changes.

  The attached patch makes rpm conservative: If a %config file was locally
  modified and the original and new packages use different hashes, it will always
  create .rpmnew/.rpmsave files.  With this change, %config(noreplace) files
  are always treated in the same way they would be treated in an all-md5
  environment.

  %config (no noreplace) files will move user's modifications to .rpmsave files
  even if the config file has not changed between two packages with different
  hashes.  Fedora guidelines suggest using noreplace in most cases (rpmlint even
  warns about %config without noreplace), so this might be good enough.

* It is impossible to share files between packages that use different hashes,
  unless the packages use different colors and rpm processes them.  This
  shouldn't impact multilib because both multilib versions are built at the
  same time, and perhaps because the color handling overrides conflicts.

  I can't think of any other reasonable use for packages with file conflicts,
  and even if there is such an use, the conflicting packages would most likely
  be built together and use the same hash type.

Perhaps using only this patch, and adding a release note to F11/F12 (as long as F10 is supported) and to RHEL5 is good enough?
  same hash type (and perhaps because rpm will
Comment 5 Panu Matilainen 2009-01-28 10:04:11 EST
Applied upstream (with slightly changed comment to fit it on one line :), thanks for the patch and testing efforts.

This will go to rawhide (and eventually F10 updates too) on next update round, but note that there's no way the digestalgo stuff is going to get backported to rpm 4.4.x. For RHEL it doesn't matter as only supported upgrade path is through anaconda where this is not an issue, for Fedora it's just preupgrade from F9 and older which wont work.
Comment 6 Fedora Update System 2009-02-07 17:22:51 EST
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rpm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1478
Comment 7 Fedora Update System 2009-02-24 15:51:40 EST
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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