%config files and upgrade to F11 - consider noreplace

[Miloslav Trmač]

Toshio Kuratomi píše v Čt 26. 02. 2009 v 08:24 -0800:
> mitr, it would help if you actually answer the question that everyone's
> trying to ask even if they aren't phrasing it right :-)
> 
> 1. rpmdb has md5 of old vanilla config file.
> 2. rpm package has sha256 of vanilla new config file.
> 3. rpm computes md5 of config on filesystem
> 4. rpm sees that md5 of config on filesystem and config of vanilla file
> differ => user has modified file.
> 5. rpm sees the vanilla hashes are of different type.
> 6. rpm computes md5 of vanilla new config file.
> 7. rpm compares md5 of both vanilla config files to determine whether
> the packager has modified the file.
> 
> You told me on IRC that this wasn't realistic because rpm would have to
> open the file twice.  Care to elaborate so everyone can understand?
RPM API users set up a callback that is, among other things, used to
provide the downloaded package file to RPM.  Calling this callback where
it wasn't called before is an API change, possibly breaking the RPM
front-ends.

Implementing the hash recomputation and verifying the API users was a
possibility, but me and Panu consider the current solution good enough -
after all, the user's modified config file would be moved to .rpmsave
even if the package maintainer only added a comment somewhere; not
handling this correctly in rpm does not put any significant additional
burden on our users.

In addition, if the hashes are recomputed, they must be recomputed only
once - decompressing a package five or ten times during a transaction
just wouldn't do - and keeping all recomputed hashes in memory would
increase memory requirements; I was told that minimizing the increase of
memory requirements was a significant reason why the RPM files do not
contain both kinds of hashes simultaneously.
	Mirek