%config files and upgrade to F11 - consider noreplace

[Bill Crawford]

On Wednesday 25 February 2009 22:01:12 Bill Nottingham wrote:

> Given that it's comparing hashes, and the old hash is *obviously* of a
> different type than the new hash, why can't these sorts of conflicts
> be caught?

The hash for the original file is stored in the rpm database, as part of the 
headers. Why wasn't a new tag created, or why doesn't the new shiny rpm mark 
the entry in some way to indicate that it's a "new" hash? Isn't the new hash 
bigger anyway? In which case it should be able to tell what kind of hash it is 
(just like the password encryption routines can recognise the difference 
between an md5 and an sha1 hash) ... and run the old checksum code on the file 
on the machine, before replacing it with the new file and the new hash.

Is this actually rocket science?