How do I use rpm to update/replace existing files?

Question

I have several applications that I wish to deploy using rpm. Some of the files in my application deployments override files from other deployed packages. Simply including the new files in the deployment package will cause rpm conflicts.

I am looking for the proper way to use rpm to update/replace already installed files.

I have already come up with a few solutions but nothing seems quite right.

• Maintain custom versions of the rpms containing the original files.

This seems like a large amount of work for a relatively small reward even though it feels less like a hack than some of the other possible solutions.

• Include the files in the rpm with another name and copy them over in the post section.

This would work but will mean littering the system with multiple copies of the files. Also it means additional maintenance in the rpm build spec for each file.

• Use wget in the post section to replace the original files from some known server.

This is similar to the copy technique but the files wouldn't even live in the rpm. This might act like a nice central configuration authority though.

• Deploy the files as new files, then use symlinks to override the originals.

This is also similar to the copy technique but with less clutter. The problem here is that some files don't behave well as symlinks.

Answer 1

To the best of my knowledge, RPM is not designed to permit updating / replacing existing files, so anything that you do is going to be a hack.

Of the options you list, I'd choose #1 as the least bad hack if the target systems are systems that I admin (as you say, it's more work but is the cleanest solution) and a combination of #2 and #4 (symlinks where possible, copies where not) if I'm creating the RPMs for others' systems (to avoid having to distribute a bunch of RPMs, but I'd make it very clear in the docs what I'm doing).

You haven't described which files need to be updated or replaced and how they need to be updated. Depending on the answers to those questions, you may have a couple of other options:

• Many programs are designed to use a single default configuration file and also to grab configuration files from a .d subdirectory. For example, Apache uses /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/*.conf, so your RPMs could drop files under /etc/httpd/conf.d instead of modifying /etc/httpd/conf/httpd.conf. And if the files that you need to modify are config files that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability; this wouldn't help you immediately but would make future releases easier.
• For command-line utilities like sendmail and lpr that can be provided by multiple packages, the alternatives system (see man alternatives) permits more than 1 RPM that provides these utilities to be installed side by side. Again, if the files that you need to modify are command-line utilities that don't follow this pattern but could be made to, you can suggest to the package maintainers that they add this capability.
• Config file changes on systems that you administer are better managed through a tool like Cfengine or Puppet rather than through custom RPMs. I think that Red Hat favors Puppet.
• If I were creating the RPMs for systems I don't administer, I'd consider using a third-party tool like Bitrock and dumping all of my stuff under /opt just so I wouldn't have to stomp on files installed by other admins' RPMs.

Answer 2

You can also execute rpm -U --replacefiles --replacepkgs ..., which will give you what you want.

Answer 3

See here for more info on RPM %files directives:

http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html

You can use the arguments from the %post and %pre sections in the RPM scriptlets to determine if you are installing, upgrading or removing packages.

If $1 is 0 - then we're removing old stuff. Targeting 0 packages installed. If $1 is 1 - then we're installing new stuff. Targeting a total of 1 package to be installed. If $1 is 2 or more - then we're upgrading this package and $1 represents the number of packages already installed.

These sections help with managing files among the versions. Keep track of what you're doing between versions and consider what one might do if they were to skip a version or two.

Have consideration for these things and you should be good to go!