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.

Reboot after applying updates to any libraries which may potentially be in use

While ANPM 1.0.2 and later will prompt when a system restart is required based upon a known set of packages being updated, it is good practice to ensure that any libraries in memory are the latest ones installed. So, when updating packages such as gcc or others which include, require, or consist solely of DLLs which may already have been loaded into memory by something before ANPM downloaded and YUM installed an update, simply reboot the system when the update process has finished. (Hint: Packages which begin with “lib” are libraries, so when updating, if any of these are picked up as dependencies, this guideline applies.)

A good example of the need for this is when updating gcc, as mentioned above. This may cause some applications (recent Mozilla applications, for instance) to fail to start, reporting something similar to the following in POPUPLOG.OS2 in the root of the boot volume:

06-06-2020 09:46:29 SYS2070 PID 0089 TID 0001 Slot 006b
O:\PROGRAMS\THUNDERBIRD\THUNDERBIRD.EXE
STDCPP6->GCC1.___gthread_os2_mutex_lock
127

To correct this, simply restart. The updated libraries will be read from disk, and dependent applications should function as expected.

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: If your %UNIXROOT% volume is JFS and was created with JFS version 1.09.07 or earlier and has not been updated to use os2boot 1.09.08 or later, do not simply create \usr\local directories and leave them empty, as this can cause a failure to boot. JFS volumes created with JFS version 1.09.08 or later do not have this problem. (For more details see the section entitled IPE when an empty directory is encountered during boot on the JFS wiki page.)

Some diagnostic utilities may warn about empty directories in %LIBPATH%. Generally, such warnings may be safely ignored for the \usr\local directories, subject to the note above.

When to use experimental packages

Many repositories are divided into two basic collections of packages:

• stable or release
• experimental

Arca Noae has additional repositories, such as subscription.

Packages in the stable or release repository should be safe to install. These have been (hopefully) well tested or pose little risk to system stability if something really does not work correctly with their installation, operation, or removal. This is also the case with the Arca Noae subscription repository, which contains release-quality packages for subscribers.

Experimental packages may be of any quality, and even completely unstable. In short, they are experimental, as the name implies. This means that they may or may not install correctly. Once installed, they may cause all manner of system chaos. They may completely wipe hard drives, network-attached drives, cause SSDs to overheat, and generally behave  erratically. They are for use by those with a certain set of skills (and intestinal fortitude), able to provide useful feedback to the packager and/or program builder, who may then be able to stabilize the package, put the newer build in the experimental repository, and continue the cycle until the package is ready to be moved stable repository for release. In short, unless you have a specific reason for doing so, you should not install and use experimental packages in a production environment, and unless you have the skills and time necessary to assist in the testing and feedback of a specific experimental package, or have been directed by someone in a position to know the risks involved in using this software (the packager and/or the program builder), you should avoid installing experimental packages.

Arca Noae’s official position is that any tickets opened against experimental packages by users who are not part of Arca Noae’s official beta test team will be summarily closed. Use of experimental packages is done so entirely at the risk of the user. No Arca Noae support subscription currently extends to the installation, use, or removal of experimental packages.

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.

This entry last updated: January 2nd, 2021 by Lewis Rosenthal