YUM, short for Yellowdog Updater, Modified, is a command-line package manager for RPM-based Linux distributions such as Red Hat Enterprise Linux, CentOS, Fedora and Oracle Linux. In package management, YUM sits above the low-level RPM tool: it downloads packages from repositories, resolves dependencies automatically and installs, updates or removes software as a consistent transaction.
YUM grew out of the Yellowdog Updater used by the Yellow Dog Linux distribution and became the standard updater of the Red Hat family in the 2000s. It was later replaced by DNF, first in Fedora and then in RHEL 8 and later, where the yum command remains available as a compatible front end to DNF. Classic Python-based YUM is still found on RHEL 7, CentOS 7 and systems derived from them.
How YUM installs and updates packages
YUM works with repositories, which are collections of RPM packages accompanied by metadata. Each repository publishes a repodata directory containing repomd.xml and compressed indexes describing every package, its version, its dependencies and the files it provides.
- Reading configuration from
/etc/yum.confand the repository files in/etc/yum.repos.d/. - Downloading and caching metadata for every enabled repository, usually under
/var/cache/yum. - Resolving dependencies for the requested operation, including packages that must be added, upgraded or removed.
- Showing the transaction summary and asking for confirmation unless
-yis used. - Downloading and verifying packages against their GPG signatures and checksums.
- Running the transaction through the RPM library, then recording it in the YUM history database.
The essential value of YUM lies in step three. Installing an RPM directly with rpm -i fails when a library is missing, whereas YUM finds the providing packages in the repositories and installs them in the right order.
Essential YUM commands
Day-to-day administration with YUM relies on a small, consistent set of subcommands. They operate on package names, globs or provided capabilities such as file paths.
| Command | Action | Typical use |
|---|---|---|
yum install httpd | Install a package with dependencies | Adding software |
yum update | Update all installed packages | Routine patching |
yum update --security | Apply only security errata | Restricted maintenance windows |
yum remove httpd | Remove a package and dependents | Uninstalling software |
yum search nginx | Search names and summaries | Finding packages |
yum provides */semanage | Find the package owning a file | Locating missing commands |
yum groupinstall "Development Tools" | Install a predefined group | Preparing build hosts |
yum history undo 42 | Reverse a past transaction | Rolling back changes |
yum clean all | Delete cached metadata and packages | Fixing stale metadata |
The history database deserves special attention. Every transaction receives a number, and yum history info shows exactly what changed. Undo works well for simple installations, but it may fail when older package versions are no longer available in the repositories.
Repositories and configuration
Each repository is defined in a .repo file with a short set of directives. Correct repository configuration determines both what can be installed and how trustworthy it is.
| Directive | Purpose | Example value |
|---|---|---|
| baseurl | Direct location of the repository | An http, https or file path |
| mirrorlist or metalink | List of mirrors to choose from | A mirror service address |
| enabled | Whether the repository is used | 1 or 0 |
| gpgcheck | Verify package signatures | 1 (recommended) |
| gpgkey | Location of the signing key | A key file under /etc/pki |
| priority | Preference among repositories (plugin) | 1 to 99, lower wins |
Common additional repositories include EPEL, which provides extra packages for Enterprise Linux, and vendor repositories for databases or monitoring agents. Mixing many third-party repositories increases the risk of conflicting package versions, so administrators often enable them only for specific commands with --enablerepo.
YUM compared with DNF, RPM and APT
YUM belongs to a layered toolchain and has close counterparts in other distribution families. The comparison shows where YUM fits and why it was eventually succeeded.
| Tool | Level | Distribution family | Dependency resolution |
|---|---|---|---|
| RPM | Low-level package tool | Red Hat family, SUSE | Checks only, does not fetch |
| YUM | High-level manager | RHEL 7 and earlier, CentOS 7 | Python-based resolver |
| DNF | High-level manager | Fedora, RHEL 8 and later | libsolv SAT solver |
| Zypper | High-level manager | openSUSE, SLES | libsolv SAT solver |
| APT | High-level manager | Debian, Ubuntu | Own resolver, works with dpkg |
DNF was created because classic YUM had slow and sometimes inconsistent dependency resolution, high memory use and an unstable plugin API. DNF uses the libsolv satellite solver, which handles complex dependency sets faster and more predictably. Most YUM commands work unchanged with DNF, which made migration largely transparent for administrators.
Plugins, pitfalls and good practice
YUM is extended through Python plugins and the companion yum-utils package. Useful extensions include versionlock to pin packages, fastestmirror to select nearby mirrors and tools such as needs-restarting and yumdownloader.
- Never disable gpgcheck for convenience; unsigned packages remove an important protection against tampering.
- Run yum clean all when repository changes do not appear, because stale cached metadata is a frequent cause.
- Avoid interrupted transactions; if one occurs,
yum-complete-transactioncan finish or clean it up. - Pin critical packages such as kernels or database servers with versionlock before unattended updates.
- Check needs-restarting after updates, since updated libraries are not used until services restart.
For systems still running classic YUM, the more important question is often lifecycle: RHEL 7 and CentOS 7 have reached the end of their standard support periods, so planning a migration to a DNF-based release is part of responsible YUM administration.
The simple explanation
YUM is like an app store for Red Hat-style Linux servers, operated by typing commands. You ask for a program by name, and YUM finds it in trusted online collections. It also downloads every other piece the program needs.
It checks that the files are genuine and installs everything in the correct order. Later, a single command brings the whole system up to date. Newer systems use a successor called DNF, but the same yum commands still work there.
How it is used in practice
An administrator maintains 30 CentOS 7 web servers in a corporate data center. During a monthly maintenance window, she runs yum update --security on a test server first, reviews the transaction summary of 18 packages, and confirms that the web application still works.
On the production servers, she applies the same update through an automation tool, with the database client pinned by the versionlock plugin. One server shows failed metadata downloads, which yum clean all resolves. Afterward, needs-restarting -r identifies the hosts that require a reboot for the new kernel. All servers are patched within the window, and the history database records every change for the audit report.