RPM Hotfix/Patch Approach

Question

We run a system on Centos 5.5 and install our software using one RPM containing all of our software. When we need to apply a hot fix or patch the current system is simply to stick on a tar and untar it.

I'm trying to develop a trackable, repeatable system for applying hot fixes and patches but I'm a little unsure as to what role RPM plays in this process.

From what I understand if we up the version number and reinstall even with just one file changed then RPM will blast the whole lot. This requires us being absolutely sure that noone has put another hotfix on the system that we're not aware of as it will be replaced.

Is it possible to make an RPM that contains JUST the new files and apply that on top of an existing RPM? How would that affect subsequent upgrades of the system?

Answer 1

The problem is changing files locally installed by the rpm and forgetting about them.

If you use this as a hotfix procedure, right after the hotfix you should build the new rpm and then deploy that new rpm.

If people are allowed to put hotfix after hotfix on top of a machine without ever committing it to the normal process, you're inviting disaster.

One thing you can do to be reminded of the fact that you have hotfixes lying around is to use

rpm -q --verify (your rpm name)

This will print a list of files that have been changed since the rpm was installed. That way you at least know which files were patched and should be taken into account.

Answer 2

The point of RPM is to have repeatable, verifiable installs. You should generate a new RPM with the update rolled into it (via a patch or new upstream source).

Splitting up your monolithic package would allow you to upgrade parts individually.

Answer 3

You can use deltarpm (but I don't recommend it, see bellow). Having old rpm and new rpm (on build machine) you can generate delta using deltarpm tool. Using deltarpm tool on box where software is installed you can then automagically upgrade old rpm to the new rpm (and downgrade it back if needed).

I don't like it because if any (non config) file provided by old rpm will get change, you will not be able to install the fix. Moreover deltarpm it is not production-ready tool. You have been warned.

As an alternative for deltarpm I will advice to split your software to few smaller RPMs and deliver subset of new RPMs as a hotfix. This is most commom approach.