21

I use yum to update my Fedora. After a huge update, I got many .rpmnew and .rpmsave files. I could understand if I had modified these files. But I'm sure that I didn't edit these files.

What should I do with these files? What will happen at the next update?

Here's a sample of these files:

/usr/share/texmf-var/fonts/map/dvipdfm/updmap/dvipdfm_dl14.map.rpmnew
/usr/share/texmf-var/fonts/map/dvipdfm/updmap/dvipdfm_dl14.map.rpmsave

Thanks

Knox
  • 2,453
  • 2
  • 26
  • 33
Luc M
  • 2,890
  • 4
  • 25
  • 27

2 Answers2

29

There are two cases:

  • If a file was installed as part of a rpm, it is a config file (i.e. marked with the %config tag), you've edited the file afterwards and you now update the rpm then the new config file (from the newer rpm) will replace your old config file (i.e. become the active file). The latter will be renamed with the .rpmsave suffix.
  • If a file was installed as part of a rpm, it is a noreplace-config file (i.e. marked with the %config(noreplace) tag), you've edited the file afterwards and you now update the rpm then your old config file will stay in place (i.e. stay active) and the new config file (from the newer rpm) will be copied to disk with the .rpmnew suffix.

See e.g. this table for all the details.

In both cases you or some program has edited the config file(s) and that's why you see the .rpmsave / .rpmnew files after the upgrade because rpm will upgrade config files silently and without backup files if the local file is untouched.

After a system upgrade it is a good idea to scan your filesystem for these files and make sure that correct config files are active and maybe merge the new contents from the .rpmnew files into the production files. You can remove the .rpmsave and .rpmnew files when you're done.

knweiss
  • 3,955
  • 23
  • 20
11

Sometimes the package manager just gets a bit confused over what constitutes a modified file or not. Usually it's because some program or another has made modifications (especially those TeX map files).

There's two approaches that I use when dealing with these sorts of files, depending on my mood, the criticality of the system, and how much I know about the file in question:

  1. After the system's been working OK for a while, just delete the ones I don't recognise as having changed (possibly dangerous, but my assumption is that if it was something really important I'd have noticed by now. Note that I only do this on "low value" systems that I can afford to spend some time fixing if I've stuffed up);
  2. Perform a unified diff (diff -u <current file> <new/save version>) between the various versions of the file, examine the output and integrate the necessary changes between the versions to bring everything up to speed, then delete the save/new files when I'm happy with things. A lot more work (although small shell scripts to find and diff the files help) but pretty much guaranteed not to break anything unless I muck up the merge.
womble
  • 95,029
  • 29
  • 173
  • 228