Package Management¶

Overview¶

Package management systems automate the process of installing, upgrading, configuring, and removing software on Linux systems. They handle dependency resolution (ensuring required libraries are present), versioning, and integration with the system's file layout.

On CentOS/RHEL, DNF (Dandified YUM) is the primary package manager, working with RPM packages from configured repositories. Understanding how to search for packages, install specific versions, apply security updates, clean caches, and manage repository configurations is a daily task for system administrators.

How It Works¶

RPM and DNF¶

On CentOS/RHEL systems, software is distributed as RPM (Red Hat Package Manager) packages — archive files containing compiled binaries, configuration files, documentation, and metadata about dependencies.

DNF (Dandified YUM) is the high-level package manager that resolves dependencies automatically. It replaces the older yum tool (though yum still works as an alias on most systems).

Core DNF operations:

# Search for a package
dnf search httpd

# Install a package
sudo dnf install httpd

# Install multiple packages at once
sudo dnf install php-mysqlnd php-fpm mariadb-server tar curl php-json

# Update all installed packages
sudo dnf update

# Remove a package
sudo dnf remove httpd

# List installed packages
dnf list installed

# Get information about a package
dnf info httpd

Repositories¶

DNF downloads packages from repositories — remote servers hosting collections of RPM packages and their metadata. Repository configurations live in /etc/yum.repos.d/ as .repo files.

A typical CentOS system has several default repositories:

BaseOS — core operating system packages
AppStream — application-level packages, including multiple versions (module streams)
EPEL (Extra Packages for Enterprise Linux) — community-maintained additional packages, often added manually

Each repository entry specifies a URL, GPG key for signature verification, and whether the repo is enabled:

[epel]
name=Extra Packages for Enterprise Linux $releasever
baseurl=https://dl.fedoraproject.org/pub/epel/$releasever/Everything/$basearch
enabled=1
gpgcheck=1

Dependency Resolution¶

When you install a package, DNF automatically identifies and installs all required dependencies. For example, installing wordpress may pull in PHP, its modules, and supporting libraries. DNF builds a dependency tree and presents the full transaction for confirmation before proceeding.

If two packages conflict (require incompatible versions of the same library), DNF will refuse the transaction and report the conflict.

Module Streams (AppStream)¶

CentOS/RHEL 8+ introduced module streams, allowing multiple versions of the same software to coexist in the repository. For example, the php module might offer streams for PHP 7.4, 8.0, and 8.1. You select a stream with:

sudo dnf module enable php:8.1
sudo dnf install php

Other Package Managers¶

While this course focuses on DNF/RPM, other ecosystems use different tools:

apt (Debian/Ubuntu) — uses .deb packages
pip (Python) — installs Python libraries (pip3 install flask)
npm (Node.js) — installs JavaScript packages

Pip and npm manage language-specific libraries and are often used alongside the system package manager. System-level dependencies (like python3, httpd, mariadb-server) should always be installed via DNF.

Key Terminology¶

RPM: Red Hat Package Manager — both the package format (.rpm files) and the low-level tool for querying and installing individual packages.
DNF: Dandified YUM — the high-level package manager that handles dependency resolution, repository management, and transactions.
Repository: A remote server hosting a collection of packages and metadata. Configured in /etc/yum.repos.d/.
Dependency: A package required by another package to function. DNF resolves these automatically.
Transaction: A set of package operations (install, update, remove) that DNF applies atomically.
GPG Key: A cryptographic signature used to verify that packages have not been tampered with.
EPEL: Extra Packages for Enterprise Linux — a widely-used third-party repository providing additional software not included in the base CentOS/RHEL repositories.
Module Stream: A mechanism for providing multiple versions of the same software within a single repository.

Why It Matters¶

Reproducibility: Installing software from packages (rather than compiling from source) ensures consistent, tested, repeatable deployments. This is critical when managing multiple servers or rebuilding after failures.
Security updates: Package managers track which versions are installed and can apply security patches across all managed software with a single dnf update command.
Dependency management: Manually tracking shared libraries and version requirements across dozens of packages is impractical. DNF handles this automatically.
Automation: Configuration management tools like Ansible use the dnf module to declare which packages should be present, making infrastructure reproducible as code.

Common Pitfalls¶

Forgetting to update before installing: Running dnf update before installing new packages ensures you have the latest repository metadata and avoids version conflicts.
Mixing pip/npm with system packages: Installing a Python library via pip that conflicts with an RPM-managed version can cause subtle breakage. Prefer DNF for system-level Python packages and use virtual environments for application-specific dependencies.
Ignoring GPG warnings: If DNF warns about unsigned or untrusted packages, investigate before proceeding. Disabling gpgcheck removes an important security layer.
Not enabling EPEL: Many commonly needed tools (like Ansible, htop, or mod_security) live in EPEL. If dnf search returns no results for a package you expect to exist, EPEL is likely not enabled.
Leaving test/development packages installed: Packages installed for debugging or testing should be removed when no longer needed to reduce attack surface and avoid confusion.