Chapter 2. Distribution of content in RHEL 9

In the following sections, learn how the software is distributed in Red Hat Enterprise Linux 9.

2.1. Repositories

Red Hat Enterprise Linux (RHEL) distributes content through different repositories, for example:

BaseOS
Content in the BaseOS repository consists of the core set of the underlying operating system functionality that provides the foundation for all installations. This content is available in the RPM format and is subject to support terms similar to those in earlier releases of RHEL.
AppStream
Content in the AppStream repository includes additional user-space applications, runtime languages, and databases in support of the varied workloads and use cases.
Important

Both the BaseOS and AppStream content sets are required by RHEL and are available in all RHEL subscriptions.

CodeReady Linux Builder
The CodeReady Linux Builder repository is available with all RHEL subscriptions. It provides additional packages for use by developers. Red Hat does not support packages included in the CodeReady Linux Builder repository.

Additional resources

2.2. Application Streams

Red Hat provides multiple versions of user-space components as Application Streams, and they are updated more frequently than the core operating system packages. This provides more flexibility to customize Red Hat Enterprise Linux (RHEL) without impacting the underlying stability of the platform or specific deployments.

Application Streams are available in the following formats:

  • RPM format
  • Modules, which are an extension to the RPM format
  • Software Collections

RHEL 9 improves Application Streams experience by providing initial Application Stream versions as RPMs, which you can install by using the dnf install command.

Starting with RHEL 9.1, Red Hat provides additional Application Stream versions as modules with a shorter life cycle.

Important

Each Application Stream has its own life cycle, and it can be the same or shorter than the life cycle of RHEL 9. See Red Hat Enterprise Linux Application Streams Life Cycle.

Always determine which version of an Application Stream you want to install, and make sure to review the RHEL Application Stream life cycle first.

Additional resources

2.3. Modules

A module is a set of RPM packages that represent a component. A typical module contains the following package types:

  • Packages with an application
  • Packages with the application-specific dependency libraries
  • Packages with documentation for the application
  • Packages with helper utilities

2.4. Module streams

Module streams are filters that can be imagined as virtual repositories in the AppStream physical repository. Module streams versions of the AppStream components. Each of the streams receives updates independently, and they can depend on other module streams.

Module streams can be active or inactive. Active streams give the system access to the RPM packages within the particular module stream, allowing the installation of the respective component version.

A stream is active in the following cases:

  • If an administrator explicitly enables it.
  • If the stream is a dependency of an enabled module.
  • If the stream is the default stream. Each module can have a default stream but in Red Hat Enterprise Linux 9, no default streams are defined. If required, you can configure default streams as described in Defining custom default module streams and profiles.

Only one stream of a particular module can be active at a given point in time. Therefore, only packages from a particular stream are available.

Prior to selecting a particular stream for a runtime user application or a developer application, consider the following:

  • Required functionality and which component versions support that functionality
  • Compatibility with your application or use case
  • The life cycle of the Application Stream and your update plan

For a list of all available modules and streams, see the Package manifest. For per-component changes, see the Release Notes.

Additional resources

2.5. Module profiles

A module profile is a list of recommended packages to be installed together for a particular use case such as for a server, client, development, minimal install, or other. These package lists can contain packages outside the module stream, usually from the BaseOS repository or the dependencies of the stream.

Installing packages by using a profile is a one-time action provided for the user’s convenience. It is also possible to install packages by using multiple profiles of the same module stream without any further preparatory steps.

Each module stream can have any number of profiles, including none. For any given module stream, some of its profiles can be marked as default and are then used for profile installation actions if you did not explicitly specify a profile. However, the existence of a default profile for a module stream is not required.

Example 2.1. nodejs module profiles

The nodejs module, which provides the Node.js runtime environment, offers the following profiles for installation: 

# dnf module list nodejs
Name 	   Stream	Profiles                                Summary
nodejs   18    	common [d], development, minimal, s2i   Javascript runtime
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

In this example, the following profiles are available:

  • common: The production-ready packages. This is the default profile ([d]).
  • development: The production-ready packages, including the Node.js development headers.
  • minimal: The smallest set of packages that provides the Node.js runtime environment.
  • s2i: Packages necessary for creating Node.js Source-to-Image (S2I) Linux containers.