Comment 5 for bug 638600

Created attachment 330021
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