How YUM Package Manager Works in Older Red Hat Linux

The Yellowdog Updater, Modified (YUM) is a command-line package management utility used in older Red Hat Enterprise Linux (RHEL) versions—primarily RHEL 5, 6, and 7—and its derivatives like CentOS and Scientific Linux. YUM acts as a high-level abstraction layer over the low-level Red Hat Package Manager (RPM). It automates the installation, updating, querying, and removal of software packages by automatically calculating and resolving software dependencies through configured network or local repositories.

Architecture and the Role of RPM

To understand YUM, it is essential to understand its relationship with RPM. RPM operates directly on individual .rpm archive files, installing them and updating a local Berkeley DB database located at /var/lib/rpm. However, RPM cannot automatically download packages from the internet, nor can it automatically fetch required dependencies; if Package A requires Library B, an attempt to install Package A via RPM simply halts with an error.

YUM solves this limitation. Written predominantly in Python with a C-based metadata-parsing backend, YUM functions as a transaction processor. It communicates with the user, fetches necessary data from remote repositories, resolves dependencies, and then calls the RPM library to execute the actual package installation or removal.

Repository Architecture and Metadata

YUM relies on centralized storage locations called repositories. These repositories are configured via /etc/yum.conf (global settings) and individual .repo configuration files located in /etc/yum.repos.d/. Each .repo file defines:

The core operational mechanism of YUM depends on repository metadata. When a repository is created on a server using the createrepo tool, it parses all the RPM headers and generates XML or SQLite files (such as repomd.xml, primary.sqlite, and filelists.sqlite).

When a user runs a YUM command, YUM downloads this metadata into a local cache directory (/var/cache/yum/). The metadata contains explicit information about:

  1. Every package available in the repository.
  2. What capabilities each package provides (binaries, shared libraries).
  3. What dependencies each package requires.

The Dependency Resolution Engine

The primary technical feat of YUM in older Red Hat systems is its dependency resolution algorithm. When a user issues a command such as yum install httpd:

  1. Metadata Parsing: YUM checks its local cache against the remote repository's repomd.xml timestamp. If the local cache is outdated, it downloads the newest metadata.
  2. Capability Mapping: YUM queries the database to identify which package provides the requested string (httpd).
  3. Dependency Tree Generation: Once the primary package is identified, YUM inspects the Requires tags within the package's header. It recursively checks whether those requirements are already met by packages in the local RPM database.
  4. Transaction Set Construction: If dependencies are missing, YUM searches the repository metadata to find packages that satisfy the missing capabilities. It repeats this process recursively until all requirements form a complete dependency tree, creating a proposed transaction set. If a conflict occurs or a dependency cannot be satisfied, the process aborts and outputs a dependency error.

Transaction Execution and Verification

Once the dependency tree is successfully resolved, YUM presents the transaction set to the user, listing the target package alongside any dependencies to be installed, upgraded, or removed, including total download size.

Upon user confirmation, the execution phase begins:

  1. Download: YUM downloads all required RPM files into the local cache.
  2. Integrity and Signature Verification: If gpgcheck=1 is set, YUM checks the cryptographic GPG signature of each downloaded RPM against imported public keys located in /etc/pki/rpm-gpg/ to prevent tampering.
  3. Pre-Transaction Testing: YUM runs a dry run using RPM to ensure no file conflicts exist (e.g., two packages attempting to write to the exact same path).
  4. Execution: YUM passes the complete transaction list to the underlying RPM library (librpm). RPM installs or updates the software and registers the changes in /var/lib/rpm.
  5. Cleanup and Logging: Depending on configuration, YUM either deletes or keeps the downloaded RPMs and writes an audit record of the operation to /var/log/yum.log.

This automated cycle—fetching remote metadata, building local dependency graphs, validating package integrity, and handing execution off to RPM—defined package management throughout RHEL 5, 6, and 7 until YUM was superseded by DNF (YUM v4) in RHEL 8.