On Wed, 2009-02-25 at 23:12 +0100, Miloslav Trmač wrote: > Bill Nottingham píše v St 25. 02. 2009 v 17:01 -0500: > > Miloslav Trmač (mitr@xxxxxxxx) said: > > > Because the Fedora 11 RPM packages will use SHA-256 for file digests in > > > the RPM headers, upgrades from earlier releases to Fedora 11 will > > > replace user-modified %config files (without noreplace) by their > > > original versions, and rename the user-modified files to *.rpmsave. > > > > > > The Fedora packaging guidelines already suggest using %config(noreplace) > > > in most cases: > > > https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files . > > > > > > Please review use of %config without noreplace in your packages, and add > > > noreplace if appropriate. The list of affected packages is below. > > > > 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? > rpm recognizes that the hash changed, but what can it do? > > - there is a config file > - the config file was modified by the user > - the update package may or may not contain a different version > of the config file than the old package. > => the only things rpm can do is: > - leave the modified config file as is > (this is what rpm does if the hashes are equal, i.e. the update > doesn't change the config file) > X if the update did update the config file, the updated config file > would not be installed - but %config means the updated config file > should be installed > X this loses data (user would have to dig into the updated rpm package > manually to get the updated config file, and would get no > notification about the unused updated config file) > - save the updated config file as .rpmnew > X there would be no difference between %config and %config(noreplace), > changing the semantics > - save the modified config file as .rpmsave > X moves modified files to .rpmsave even if the update doesn't change > the config file As already pointed out by someone else before. RPM could compute on-the-fly the old (MD5) hash of the new config file being installed and use that for the comparsion. Except this may not be easily hackable into the RPM code I suppose because the file is possibly not yet extracted from the cpio at the time the hashes are compared. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
