Dealing with .rpmnew and .rpmsave files

Nobody ever thinks to mention .rpmnew and .rpmsave extensions to new users of Fedora or Red Hat derivatives. Instead, most users suddenly discover that these files are accumulating on their hard drives, or notice a fleeting message on the screen about them during a version upgrade. Many, I suspect, simply leave them alone, uncertain what to do about them. Yet dealing with them is simply a matter of using a few basic commands, and can be a necessity for ensuring trouble-free upgrades in the future.

Both .rpmnew and .rpmsave files are the result of a cautious upgrade policy in .RPM packages. When an upgrade includes changes to a default configuration file, instead of overwriting the configuration file on your system — and possibly nuking the changes you have made — the package will write one of these file types. An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched. By contrast, and .rpmsave file is a copy of your original configuration file, which has been replaced by the new default file.

Which file a package creates is up to the discretion of the package maintainer. However, if the recent upgrade to Fedora 8 is typical, almost all maintainers choose to use rpmnew files, which is the less obtrusive choice. After all, if you have added, for instance, multiple keyboard configurations to /etc/X11/xorg.conf, the last thing you want is for an upgrade to overwrite your modifications and force you to redo them.

However, no matter which file is added to your system, you still need to know to know how to deal with it. Some users simply delete all .rpmnew and .rpmsave files — a move that is tempting after a major upgrade, when you typically have dozens of files to manage, but which defeats the point of the policy behind the files.

If you do not have the patience to examine all the .rpmnew and .rpmsave files, a more reasonable approach is to examine carefully only those files that are likely affect overall system performance — which mostly means those files in /etc, the top-level directory that holds most configuration files. Files outside /etc are less crucial, and in most cases should not affect the entire operating system, although you should still proceed cautiously.

Generally, you should examine your system for .rpmnew and .rpmsave files after every upgrade, especially major ones. Your first problem, though, is to find them. Fedora-like systems no longer keep an upgrade log in the /root directory, as they did in earlier versions. Nor is there a record in /var/log, as might be expected.

The easiest way to locate them is by using one of the desktop search tools to scan the entire file system, or opening a command line while logged in as the root user and entering find / -print | egrep "rpmnew$|rpmsave$" to search the system from the root directory down and print the full path to each of the files found.

Armed with this list, you can compare each modified and original file, both of which are in the same directory. You could make your comparison by opening up both the modified and original versions in separate windows of a text editor, but this is one case where the command line is easier.

Instead of trusting your powers of concentration not to miss any changes, use the command diff file1 file2. Lines unique to the first file are displayed with a greater than sign (>) at their start, while lines unique to the second file start with a less than sign (<). You might also consider using the -y option to display the the two files in two columns, or -c to print differences with surrounding lines so you can understand their context better. The man page for the diff command displays other options that you might want to explore.

Armed with this list of differences, you can decide whether the .rpmnew file can be deleted, whether you should overwrite the new configuration file with .rpmsave, or create a new file that includes aspects of both the files you are comparing. If the differences in the upgrade version are all additions, you can automate the process by using the command cat file1 file2 > outputfile, then renaming the output file so that it becomes the new configuration file. Otherwise, you can copy and paste as needed. Needless to say, whatever your decision, you should back up all files before deleting or overwriting them, just in case a reboot proves that you need to reconsider their use.

Of course, how well you can make decisions based on the list of differences depends on your general knowledge of GNU/Linux. Yet even if you are a relatively new user, you can use the list to find out more about the changes.

For example, when I upgraded Fedora 8, I noticed that the .rpmnew version of /etc/modprobe.d/blacklist, the file that specifies which modules the kernel should not load when booting, included a line for bcm43xx. If I did not already know what that was, I could do a Web search and discover that this line is a reference to the firmware-cutter for Broadcom wireless cards, which allows GNU/Linux to use some models of wireless cards for which no native drivers exist. If I were using one of the cards the firmware-cutter is designed for, I would probably want to delete this line from the final blacklist file.

These comparisons can take time, and are likely to be tedious. However, once you have dealt with all the .rpmnew and .rpmsave on your hard drive, you should consider installing yum-merge-conf, a recent plugin for yum, the command behind Pirut and Pup, the graphical package manager and updater for Fedora-like distributions. It lets you handle this process on the fly as you install, and avoid having to deal with these files later. To use the plugin requires that you use yum for your updates.

Whatever solution you adopt, remember that dealing with .rpmnew and .rpmsave files is a basic part of system maintenance on Fedora-like systems. If you ignore these files, your system may not be tuned to get the most out of your upgrades. It may also be less secure than it should be. In the worst case scenario, you may find that your next major upgrade has problems because some packages assume that you are using the latest default configuration. These things may not happen, but the possibility still makes dealing with the changes in .rpmnew and .rpmsave files a precaution worth taking.