Introduction to Application Streams in Red Hat Enterprise Linux

Red Hat Enterprise Linux 8 comes with a new feature called Application Streams (AppStreams), in which multiple versions of packages are provided, with a known period of support. These modules can be thought of as package groups that represent an application, a set of tools, or runtime languages. 

Each of these modules can have different streams, which represent different versions of software, giving the user the option to use whichever version best suits their needs. Each module will also have installation profiles, which help to define a specific use case, and will determine which packages are installed on the system.

* Estimated timeline of support, for more information on life cycles please visit Red Hat Enterprise Linux 8 Application Streams Life Cycle

Modularity and AppStreams provide users access to newer versions of software while being supported longer. In the past users would typically have one or two versions to work with throughout the lifecycle of the operating system. Now users will have more choices when it comes to versions of popular languages and tools.

Starting with RHEL 8, Red Hat Software Collections along with Extras, Dotnet, and Devtools will be moved into and replaced by the Appstream repository. 

Installing Applications via Modules

First things first, let's take a look at which modules are currently available to us after a fresh installation of RHEL 8. 

We can display modules using yum and see what modules and AppStreams are available to us.

# yum module list                                    # lists all modules

As you can see there are quite a few already provided in the base installation. For our demonstration we are going to use one of the PostgreSQL modules. Let's take a look at which versions, or AppStreams are available for PostgreSQL.

# yum module info postgresql          # lists all modules for postgresql

From this output we can see there are several AppStreams of PostgreSQL to work with. For now we are going to use stream 10, or version 10 of PostgreSQL, as it’s the default.  

Each module will display pertinent information including stream version, profiles, repos, summary, description, and artifacts. We’ll delve a little deeper into some of these later, but for now we can see the stream version as 10, which also has a [d] and [a] next to it. These mean that this module version is the [d]efault and [a]ctive version that will be installed should a user attempt to install PostgreSQL via yum. If no stream is specified, the default and enabled one will always be installed.

Here is an example that we can break down to show all the options.

# yum install @module:version/profile

• @module defines which module we are going to use.

• :version specifies which stream we are going to use for the specified module. 

• /profile tells us which profile to use. If no profile is specified, the default one is used. If no default is defined, then the module is only enabled but no packages are installed.

Let’s go ahead and install the PostgreSQL module using just the defaults.

# yum install @postgresql   # installs the default, PostgreSQL 10 module

Since we did not specify a stream or a profile, we can see that the defaults were used for both AppStream and profile. What if we don't want to use the defaults then? Let’s continue to see how we switch between different AppStreams and profiles.

Switching between different AppStreams in a module

A common challenge that Red Hat system administrators face are requests to install newer versions of applications then are included in the base RHEL repositories. With modules we can seamlessly change between available versions of a particular RPM.

How is that different from Red Hat Software Collections you might ask? Software Collections keeps multiple versions on one system, putting each package into separate namespaced paths. Modularity uses the standard RPM packaging, so paths are where you expect them to be. Keep in mind, unlike Software Collections, modules do not allow running multiple versions at the same time. Only one stream can be installed and used at a time.  

We’re going to continue to use PostgreSQL, but for this example our application team is requesting we move to a newer version.

Let's see which AppStreams of PostgreSQL are available to us.

# yum module info postgresql              # Lists all AppStreams available                   

Here we can see there is a newer version of PostgreSQL available to us through modules.

Before we can go ahead and install a newer version of PostgreSQL, we will need to reset the current module used and then install the newer version, specifying the stream.

# yum module reset PostgreSQL                    #Resets postgresql module

As you can see when we reset the module, the streams of that module are set to their initial state, neither enabled nor disabled. If a module has a default stream, in this case stream 10 for PostgreSQL, then it becomes active after the reset.

Now we can specify a newer stream and in this case, since there are no default profiles, we are going to select the server one. In the event a stream does not have a default profile specified with a [d] next to it, if you do not specify a profile, the stream will be enabled but no packages will be installed.

# yum module install postgresql:12/server            #Installs stream 12 

We can see that stream 12 has been enabled, the server profile will be used, and the PostgreSQL version 12 packages will be installed. If you wish to revert back to a previous stream, you just reset the profile as before, and specify an earlier stream during install.

Summary and Closing

AppStreams and modular content are great new tools, giving greater flexibility to users on which software to install, all while staying supported for longer. Our hope is that with the module build pipeline and client tooling made available, it will enable developers to continue to provide multiple versions of software. For additional information and documentation on usage and the AppStream life cycle you can visit Installing, Managing, And Removing User-Space Components.

You can find more about Appstream life cycles here: Red Hat Enterprise Linux 8 Application Streams Life Cycle.