RPM Upgrade Process

Installing software for the first time is the simplest case of deployment. The target system lacks your package's daemons, binaries, configuration files, and/or data files, so a first installation need not stop work in progress or back up, restore, and possibly merge files.

However, if the target system has a prior or current version of your software, or if your software is intertwined with other code and services, your RPM must take special care to maintain a workable configuration. You may need to halt processes, swap or preserve files, and restart applications after your new code has been copied to the system. Of course, it isn't always possible to maintain backward compatibility. In those instances, your RPM should make the fewest changes possible to keep the system functional and secure. In some cases, that may mean elaborate scripts to interpret old settings and transform them into new ones.

RPM provides four hooks for injecting commands into the installation and uninstallation sequences: two for installation and two for uninstallation. All hooks run on the target system and are generally sufficient for most housekeeping chores. These four hooks are:

• All commands listed in the %pre hook run before your package is installed.
• Commands in the %post hook run after your package has been installed.
• The %preun hook runs before your package is removed from the system.
• Commands in the %postun hook run after your package is removed from the system.

Hence, the order of operations during an upgrade is:

1. Run the %pre section of the RPM being installed.
2. Install the files that the RPM provides.
3. Run the %post section of the RPM.
4. Run the %preun of the old package.
5. Delete any old files not overwritten by the newer version. (This step deletes files that the new package does not require.)
6. Run the %postun hook of the old package.

Steps 4 and 6 may seem a bit suspect, and for good reason: If you are upgrading a package, running the older version's uninstallation hooks could undo portions or all of steps 1 through 3. In fact, without conditions, the uninstallation hooks of the older version could destroy the newer version. To prevent unintentional clobbering, RPM passes each hook one argument, a flag. The value of the flag indicates which operation is being performed:

• If the first argument to %pre is 1, the RPM operation is an initial installation. If the argument to %pre is 2, the operation is an upgrade from an existing version to a new one.
• Similarly, the arguments to a %post are 1 and 2 for a new installation and upgrade, respectively. (Again, %pre and %post aren't executed during an uninstallation.)
• If the first argument to %preun and %postun is 1, the action is an upgrade.
• If the first argument to %preun and %postun is 0, the action is uninstallation.

Wrap each of your hooks with logic to test the value of the argument and execute the correct code. By default, each hook is interpreted as a Bourne shell (typically, /bin/sh) script, unless you name another script interpreter, such as Perl.