Learn Rocky Linux - Repositories, Modules & AppStream
Episode 5 of 23

Learn Rocky Linux - Repositories, Modules & AppStream

This episode dissects the Rocky Linux repository system: the role of BaseOS, AppStream, CRB, Extras, and Devel, third-party repositories like EPEL, and module streams that allow multiple application versions to coexist within a single repository.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Introduction

In the previous episode 4, you became familiar with dnf5 install and dnf5 upgrade. But where do those packages actually come from? The answer: from repositories — structured collections of packages managed centrally. And here lies one of Rocky Linux's and RHEL's unique traits: repositories are split into several categories with different roles, along with the introduction of the module streams model that changes how you think about application versions.

Imagine repositories like shelves in a software warehouse. There's a shelf for rarely-changing core system components, a shelf for applications whose versions update frequently, a dedicated shelf for development tools, and an additional shelf from third parties. If you understand which shelf holds what, you know where to look — and more importantly, where an application's version comes from.

Understanding the Core Repositories

BaseOS and AppStream

Since RHEL 8, repositories have been split into two main categories: BaseOS and AppStream.

BaseOS contains the core operating system components — the kernel, glibc, systemd, and the base libraries that form the foundation. Package versions here tend to be stable and rarely change major versions; changes focus on bug and security fixes. You rarely interact with BaseOS directly because almost everything you install day-to-day doesn't come from here.

AppStream is where applications and runtimes live — web servers like nginx and httpd, programming languages like Node.js and Python, databases like PostgreSQL and MariaDB, and administration tools. This is where the module model works, allowing several versions of the same application to be available at once.

Melihat repositori aktif
dnf5 repolist

This command displays the active repositories along with their status. You'll see baseos and appstream at the top, followed by other repositories depending on your configuration.

CRB, Extras, and Devel

Three supporting repositories complete this landscape:

  • CRB (CodeReady Builder) — contains libraries and packages for building and development. It's often needed when compiling software from source, which is why many tutorials ask you to enable it.
  • Extras — additional packages managed by the Rocky community, such as auxiliary repos and special utilities.
  • Devel — build variants of packages with different configurations from the release versions.
Mengaktifkan CRB
dnf5 config-manager setopt crb.enabled=1

CRB is not enabled by default because most server systems don't need it — the same minimal-surface principle as the software set choice in episode 3.

Third-Party Repositories

EPEL

EPEL (Extra Packages for Enterprise Linux) is a community repository providing thousands of additional packages — popular software that doesn't ship with RHEL due to policy or licensing. EPEL works on Rocky Linux without modification thanks to binary compatibility with RHEL:

Menginstal EPEL
dnf5 install epel-release

Once installed, you can search for packages that weren't available before, such as monitoring tools or additional development utilities. EPEL is the safest and most recommended third-party repository for Rocky Linux.

RPM Fusion and Others

For multimedia and non-free packages, RPM Fusion is a common choice — but it's more relevant for desktops than servers. The principle is the same as for other third-party repositories: only add repositories from trusted sources, and always mind the gpgcheck policy and GPG signatures we covered in episode 4.

Warning

Every third-party repository adds an attack surface: the more package sources you have, the higher the chance of conflicts or malicious packages. Add only the repositories you truly need, and keep official sources as the priority.

Module Streams in AppStream

The Module Concept

The module model is RHEL's answer to a classic problem: how do you provide several different versions of an application in a single operating system? A module packages the application, its dependencies, and its metadata as a single unit whose version can be selected — called a stream.

The most concrete example is Node.js. In Rocky 9's AppStream, you can choose the nodejs:18, nodejs:20, or nodejs:22 stream — each a different major version, complete with matching runtimes and dependencies.

Melihat modul yang tersedia
dnf5 module list nodejs

Enabling a Stream

Selecting a stream is done with the enable command, then installing the desired profile:

Mengaktifkan stream nodejs:20
dnf5 module enable nodejs:20
Menginstal profil modul
dnf5 module install nodejs:20/default

Once enabled, that stream becomes the default version installed when you run dnf5 install nodejs. It's important to understand that only one stream of a module can be active at a time — you can't have nodejs:18 and nodejs:20 active simultaneously on a single system.

Example: PostgreSQL

The same principle applies to databases:

Melihat stream postgresql
dnf5 module list postgresql
Mengaktifkan postgresql:16
dnf5 module enable postgresql:16
dnf5 install postgresql-server

The ability to select a stream like postgresql:16 gives you great flexibility: you can match the application version to your project's needs without waiting on vendor repositories.

Multiple Versions: AppStream vs Multiple Repos

A common question: what's the difference between having several versions in AppStream and adding several repositories that each provide a different version?

The key difference is in integration and management. Streams in AppStream are centrally managed by Rocky/RHEL — they're consistent with the system, tested together, and enabled with simple dnf commands. Third-party repositories, on the other hand, bring versions that may not be in sync with the system, risk dependency conflicts, and demand manual maintenance.

Membandingkan versi dari berbagai sumber
dnf5 repoquery --duplicates

So the practical guideline is: use AppStream streams for common version needs, and third-party repositories only when the required version truly isn't available elsewhere.

Closing

In this episode 5, you understood the Rocky Linux repository ecosystem: the roles of BaseOS and AppStream as the foundation and application home, CRB for development, Extras and Devel as complements, EPEL as the primary third-party package source, and the module streams model that lets multiple application versions be managed within one repository in an integrated way.

Key takeaways:

  • BaseOS carries core system components; AppStream carries applications and runtimes.
  • CRB is needed for building from source; enable it with dnf5 config-manager setopt crb.enabled=1.
  • EPEL is the safest third-party repository for Rocky Linux.
  • Module streams like nodejs:20 or postgresql:16 allow version selection, with one stream active per module.
  • AppStream streams are more integrated and safer than stacking many third-party repositories.

In the next episode 6, we will discuss user, group, and privilege management — creating and managing users and groups, the passwd, shadow, and group files, sudoers configuration with the least privilege principle, and access control with permissions, ACLs, capabilities, and SUID/SGID. The system foundation is ready; now it's time for the humans accessing it!

Learn Rocky Linux - Repositories, Modules & AppStream | Learn Rocky Linux