Miloslav Trmač wrote: > Tom Lane píše v Po 23. 02. 2009 v 13:08 -0500: >> Jon Masters <jcm@xxxxxxxxxx> writes: >>> However, I don't think enough consideration was given to the upgrade >>> path. As I raise on IRC, due to this change rpm will now consider *all* >>> local config files to have been changed by the user and use .rpmnew >>> files at upgrade time. I don't think enough consideration has been given >>> to this, to the impact upon upgrade, or to the need to ensure that >>> everyone doing an upgrade is aware of this. > (This only affects %config, not %config(noreplace).) > >> Seems like an RPM bug to me. Why should a hash change cause a local >> config file to be considered modified? Surely it's either identical >> to the RPM's file, or not. > If the user has changed a configuration file, rpm needs to know on > upgrade whether the configuration file was changed by the packager > between the two package versions. The unmodified configuration file for > the old version is no longer available, so rpm can only compare the > hashes. > It seems like rpm could do this but it would be slower and another code path: existing rpm database has old type hash. rpm knows whether existing /etc/foo.conf has changed b/c of that hash. if the file has not changed, proceed to update as normal. if the file has changed: New rpm has an /etc/foo.conf and a new type of hash. rpm needs to compute the old type hash of the new package's foo.conf file. If the old-type hash of the new foo.conf matches the hash in the rpm db, then the update should continue knowing that the config file was the same in the old package. If the old-type hash of the new foo.conf does not match the hash in the rpm db, then the update should continue knowing that the config file has changed between package updates. Am I missing the problem? -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
