RPM & YUM Best Practices

Wikis > Package Manager > RPM & YUM Best Practices

Best practices for maintaining systems with RPM & YUM

Even a package manager needs management. Installing and removing packages outside the package manager (via RPM directly) also requires following some guidelines to avoid unnecessary difficulty. The notes on this page should help provide some best practice rules of thumb for RPM, YUM, and Arca Noae Package Manager (ANPM).

Look before you leap: Don’t just blindly select Update all from the YUM menu
(ANPM versions before 1.0.2)

While it is convenient to just select YUM | Update all from the menu, this is very rarely a wise thing to do. If you do select this, take time to review the updates which are about to be applied, and check for any which should be applied in a particular order (see below). A couple of minutes here may save hours of frustrating cleanup and recovery later.

ANPM 1.0.2 and later is smarter about the ordering of installing updates and when to reboot along the way. Still, there is no substitute for paying close attention to what you are installing, and in what order. Hint: If your ANPM main menu has a YUM entry on it, this is a version before 1.0.2.

When available, update libc, libcx, and libgcc1 first, then reboot
(ANPM versions before 1.0.2)

Because so many things depend upon these two libraries, and because many of those packages do not specify which minimum version of each is required, simply unlocking an already-loaded copy in order to install an update may fail to properly load the new version when a dependent program loads, leading to a failure of that dependent application.

If a libc or libcx update is available, select that first (generally, both of these will show updates available at the same time, and if so, select both as a set). Apply the update, then close all running applications, reboot, and check for updates again. This will help ensure that any other updates will have their main dependencies met, and while there are other libraries which may also be locked in memory, these are the generally the most often in use.

ANPM 1.0.2 and later will automatically prompt when updates to critical files have been installed. There are times, however, when modules which have been unlocked which are not normally considered critical will require a reboot for the updated (or downgraded) versions to be usable. Hopefully, YUM or RPM will be enhanced to notify as to when such action is necessary.

Apply os2-base next
(ANPM versions before 1.0.2)

This is one of those things which is specific to OS/2, and not related to other platforms which utilize RPM or a package manager such as YUM or ANPM.

When checking for available updates, look for an updated os2-base package. Often, this package will include changes to filesystem layout or the platform file. These changes may impact which other packages should be chosen for update. Also, if the installed platform file has been damaged or is missing, you may find that you end up installing i386 packages instead of the expected i686 or pentium4 architecture packages.

ANPM 1.0.2 and later will install these after priority 1 packages (libc, libcx, and libgcc1) and the post-priority-1 reboot. A post-install reboot is typically not necessary.

Look for other os2- packages
(ANPM versions before 1.0.2)

Other os2- packages may be virtual packages (e.g., os2-mm, os2-tcpip) which simply serve to update the RPM database that these OS/2 components have been installed on the system, satisfying any dependencies upon them. Other os2- packages (e.g., os2-release) provide necessary information for the package manager to select the proper repository subdirectory for the system. In general, update these after os2-base, and before installing or updating other packages.

ANPM 1.0.2 and later will handle these automatically, assuming they are updates to already-installed files or they have been manually selected. That is to say that when os2- packages have been requested they will be installed after higher priority packages.

Apply RPM, YUM, and Python-related updates next
(ANPM versions before 1.0.2)

The core of the installation engine consists of YUM, which is driven by the Python scripting engine, and which in turn calls RPM to do the low level work of manipulating the packages. Many times, packages will depend upon updated features in one or more of these components for proper installation. So, once you get libc and libcx out of the way and deal with the os2- packages, it is wise to update your installation engine. After this, install, update, and remove as desired.

ANPM 1.0.2 and later will install these next, assuming all higher priority packages have been handled.

Don’t mix manually-installed packages (zips) with YUM or ANPM-maintained ones

There is a natural temptation to “just get it working.” This is fine, and we often have a need to “just get it working” and deal with making it neat, later. However, there is a right way and a wrong way to do this.

Wrong way: Unzipping a package downloaded from Hobbes (or sent via email by a well-meaning friend) into the %UNIXROOT% without paying attention to where the included directories in the package are going, often overlaying existing files of the same names from YUM or ANPM-maintained packages is a sure-fire recipe for disaster, as the versions in the RPM database may no longer match what has been extracted on top of them.

Right way: Create local directories under \usr as in:

\usr\local\bin
\usr\local\lib
\usr\local\share
\usr\local\sbin

 

Listing %UNIXROOT%\usr\local\bin and %UNIXROOT%\usr\local\sbin ahead of %UNIXROOT%\usr\bin and %UNIXROOT%\usr\sbin in PATH and %UNIXROOT%\usr\local\lib ahead of %UNIXROOT%\usr\lib in LIBPATH will ensure that your new versions are loaded first. You may then either leave the YUM or ANPM-maintained packages in place (and possibly remove the newly unzipped ones if they don’t work as expected) or uninstall the maintained packages with ANPM, without any concern that the database may be negatively impacted by any mismatched but identically named versions.

Note: Do not simply create \usr\local and leave the directory empty, as this can cause a failure to boot on JFS (possibly on HPFS, as well). Create at least the \usr\local\bin and \usr\local\sbin directories.

Reclaiming filesystem space for removed repositories

When a repository has been removed, the cached metadata and any previously downloaded packages will remain, untouched. YUM has no mechanism for handling this. To reclaim that space, it is necessary to prune the directory tree starting at the repository. For example, if removing a repository named xyz-release, the following files should be deleted from the %UNIXROOT% filesystem:

\var\cache\yum\xyz-release\packages\*
\var\cache\xyz-release\*

 

Finally, the following directories should be removed from the %UNIXROOT% filesystem:

\var\cache\yum\xyz-release\packages
\var\cache\xyz-release

 

Remember that if the %DELDIR% variable has been set to include the drive referenced by %UNIXROOT%, deleting files may result in them being moved to the \DELETE directory. It may be desirable to disable this feature or use a utility with the capability of bypassing the feature (force deletion) in order to truly reclaim the space. In general, there is no need to maintain this cached data unless there are downloaded packages which may be desired.