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.

I appreciate any help that you guys can give me.

Thanks!

Answer 1

Did you check the rpm documentation and mailing list? Here's one about rpmsave and rpmnew that covers your problem: http://www.redhat.com/archives/fedora-list/2003-December/msg04713.html

Answer 2

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 3

We used #4 at my work and were quite satisfied. The benefits is that you can still use --verify option on your packages, and use a %verify rule that makes sure the symlinks are installed. We only got burned because our %post install section wasn't written correctly, but we worked those bugs out.