Managing Software Streams and Community Packages in AlmaLinux 9

The Challenge of Binary Compatibility and Package Availability

When deploying AlmaLinux 9, the primary goal is often to maintain strict binary compatibility with Red Hat Enterprise Linux (RHEL) 9 while accessing a broader set of community-driven tools. The challenge lies in navigating the AppStream architecture—which allows multiple versions of the same software to coexist in different "streams"—and integrating the Extra Packages for Enterprise Linux (EPEL) repository without introducing dependency conflicts.

The takeaway: To maintain a stable, RHEL-compatible environment, you must leverage AppStream for core application versions and EPEL for supplemental tools, ensuring that community packages do not override critical system binaries.

Prerequisites

• A system running AlmaLinux 9 (verified via cat /etc/redhat-release).
• Root or sudo privileges for package management.
• Active internet connectivity to reach the AlmaLinux and Fedora project mirrors.

Configuring the AppStream and EPEL Repositories

AlmaLinux uses the dnf package manager. By default, the almalinux-release package configures the BaseOS and AppStream repositories. BaseOS contains the minimal set of packages required to run the system, while AppStream contains the user-space applications and languages.

Step 1: Verify Base Repository Status

Before adding external sources, confirm the internal repositories are active. Run this on the terminal as a user with sudo permissions:

sudo dnf repolist

Expected Result: You should see appstream and baseos listed in the output. If these are missing, the almalinux-release package may be corrupted or missing.

Step 2: Installing the EPEL Repository

EPEL provides packages that are not included in the standard RHEL/AlmaLinux distribution. Because these are community-maintained, they are kept in a separate repository to prevent them from replacing core system packages.

sudo dnf install epel-release

Risk: Installing EPEL allows the installation of packages that may have different update cycles than the core OS. Always verify the specific package version before deploying to production.

Working with Modular Streams

AppStream utilizes Modules, which are collections of packages that can be versioned. For example, you might need a specific version of Node.js or Python that differs from the default provided by the OS.

Example: Selecting a Specific Software Stream

To see available streams for a specific application (e.g., Node.js), use the following command:

sudo dnf module list nodejs

To switch to a specific version, such as stream 18, run:

sudo dnf module enable nodejs:18

Then install the package:

sudo dnf install nodejs

Diagnostic: Verifying Binary Compatibility

To ensure a package provided by AlmaLinux is compatible with the RHEL 9 build, you can use the provides command to check the source and metadata of a specific binary:

dnf provides /usr/bin/bash

This confirms which package provides the binary and which repository it originates from, ensuring you aren't accidentally using a third-party version of a core system tool.

Verification and System Health Checks

After configuring repositories and streams, perform these checks to ensure system integrity:

1. Repository Reachability: Run dnf repolist again to ensure epel is listed and active.
2. Release Version: Run rpm -q almalinux-release to confirm the release metadata is intact.
3. Dependency Check: Run sudo dnf check to identify any broken dependencies or duplicate packages caused by mixing streams.

Recovery and Rollback

If a modular stream installation causes application instability, you must reset the module state before attempting a reinstall.

To rollback a module stream:

sudo dnf module reset nodejs

This removes the stream preference and returns the package manager to the default state. You can then install a different version or the default version provided by the AppStream repository.