RPM spec files have a macro, %config, that is used to mark config files so that edits to config files won't get lost during a subsequent upgrade. Without this, the config files from an upgrade would tend to overrite the edited files from the previous version. %config can also apper as %config(noreplace), but there seems to be little or no documentation on what this means. Here are the results of some experimentation. The experiments were done on the current version of RPM for RedHat 9 (ver 4.2 from the rpm-4.2-0.69 RPM). Other versions may be different.
There are three things that can vary about files in an RPM that is being upgraded: how the files are marked in the spec file (default, %config, or %config(noreplace)), whether the file itself changed between RPM versions, and whether the file on disk has been edited between installing one version of the RPM and the next.
The following table shows what we ended up with after installing an RPM, optionally editing the resulting files, and then upgrading the RPM.
| File marked as | Changed in update RPM? | On-disk file untouched | On-disk file edited |
|---|---|---|---|
| [default] | No | File from update | File from update |
| Yes | File from update | File from update | |
| %config | No | File from update | Edited file |
| Yes | File from update | File from update, edited file in .rpmsave | |
| %config(noreplace) | No | File from update | Edited file |
| Yes | File from update | Edited file, file from the update in .rpmnew |
For the two cases where (noreplace) has an effect, there is also the question of what happens if the status of the file as defined in the spec file changes. And the answer is:
| File marked as | Changed in update RPM? | On-disk file edited |
|---|---|---|
| Was %config(noreplace), becomes %config | Yes | File from update, edited file in .rpmsave |
| Was %config, becomes %config(noreplace) |
Yes | Edited file, file from the update in .rpmnew |
In summary: if a file is not marked as a config file, or if a file has not been altered since installation, then it will be sliently replaced by the version from an update RPM. If a config file has been edited on disk, but is not actually different from one RPM to another then the edited version will be silently left in place. It is only when a config file has been edited and is different from one RPM to the next that what happens depens on the (noreplace) option. If absent, the new file will be installed, and the the old edited version will be renamed with a .rpmsave suffix. If present, the edited version will be left in place, and the new version will be installed with a .rpmnew suffix. I don't know what happens if RPM needs to create an .rpmsave or .rpmnew file and one already exists - at least in some cases it seems that the new file isn't written under these circumstances.
This suggests that in general config files should be marked (noreplace), unless the change being implimented is sufficiently major that a config file derived from a previous install is simpy not going to work. Even then it seens questionalble to me if installing a new 'default' configuration files is better or worse than leaving behind an edited one that may not work. YMMV.