On Wed 13 Aug 2003 08:04, John Allen posted as excerpted below: > On Wednesday 13 August 2003 11:31, Guillaume Cottenceau wrote: > > John Allen <[EMAIL PROTECTED]> writes: > > > Rpmdrake should do a diff of .rpmnew/.rpmsave and if no changes are > > > detected, zap the rpmsave, or use .rpmnew automatically. This will > > > reduce the amount of files you have to manually inspect. > > > > Is it normal at first place that a .rpmnew is created which > > contents is the same as the config file? > > Well I'm getting lots of them when I use rpmdrake to do updates. I know it > is the underlying rpm that creates .rpmsave, and .rpmnew files, but > rpmdrake could just use the .rpmnew, and delete the .rpmsave when there are > no actual differences.
I am sure someone will correct me if I'm wrong, as I'm by no means an expert, but this is the conclusion I've come to by watching the behavior over various upgrades here. 1) RPM stores the md5 sum of the various files in a package in its database. One can get a report on the files that have changed from those in the original package by doing an rpm -V <package>, with the returned format listing consisting of any file that's changed, and a flag list of what aspect has changed, date, size, md5sum, etc. 2) As far as I've been able to conclude, at upgrade time, rpm checks config files, and directly replaces any that return as unchanged from the last package. Any that return as changed aren't replaced, but rather, rpm installs the new config file as file.rpmnew, retaining any customizations you've made to the configuration. Of course, upgrades may include new or changed features, and a manual reconciliation and merge of differences may be necessary. However, that's far better than totally and arbitrarily overwriting any customizations you may have made, while still leaving a copy of the new uncustomized version conveniently available where one can view it and incorporate any new config changes into the old customized version if desired/necessary. 3) The same basic process occurs at rpm uninstall, with unchanged config files uninstalling cleanly, since if one installs the package again, they just get non-customized installed once again, but any config files that were changed are not removed, but rather renamed with the .rpmsave extension. Thus, if the package is reinstalled, one can easily recustomize it if necessary by just replacing the uncustomized config file with the rpmsave version. Of course if a newer version is installed, a manual merge or reconciliation may be necessary, as is the case with upgrades and .rpmnew files. Thus, if those files are being created, it's a sign that rpm thinks the original config files were modified/customized and thus doesn't want to overwrite them. Of course, keep in mind that you may not have edited them directly for them to be changed (think a gui config helper app changing them), but if they indeed haven't changed, and rpm is constantly installing duplicate rpmnew config files, you may have a corrupt rpm database, which thus thinks that even unchanged config files are different. Again, one can verify what RPM thinks has changed on an individual package by using the verify package switch (-V) on rpm. If your database is indeed corrupted, a --rebuilddb or similar may be required. See the man page for the appropriate switch and its correct usage. Hope that helps, and again, I don't claim to be an expert, and am only reporting what I've observed and the conclusions I've reached based on that that make the most sense to me given what I've seen. Again, should any of this be wrong, please someone, correct me as necessary. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
