With the introduction of Red Hat Enterprise Linux 8 (RHEL 8) we have tried to greatly simplify the layout of the content available in Red Hat Enterprise Linux. The main repository, BaseOS, provides the parts of the distribution that give you a running userspace on physical hardware, a virtual machine, a cloud instance or a container. The Application Stream (AppStream) repository provides all the applications you might want to run in a given userspace. The Supplemental repository provides other software that has special licensing. The CodeReady Linux Builder provides mostly build time components for developers (see Introducing CodeReady Linux Builder).
As a result, most RHEL 8 systems will only need two repositories enabled. However, this may lead to the the question, where do I find alternate versions of software if there is only 1 application repository? In prior versions, you would look to the RHSCL or Extras repositories. However, in RHEL 8, through a new technology called Modularity, we can offer those alternate versions in the same physical repository.
The simplest way to think about it is that we can hide parts of a repository from the package manager. In other words, we create multiple virtual repositories within one physical repository. We call these virtual repositories Application Streams (AppStreams)
So the word "application" is obvious, but why "stream"? Well, we want to differentiate this tooling from a classic solution to the "wrong version" problem, pinning. Pinning is what many users do to retain an existing version of software even after the Distribution has moved on. There are a number of problems with pinning but the simplest is that you don't get updates to the software, by design, which, unfortunately, includes security and bug fix updates. With the Application Streams, as you are locked to the Stream, the stream continues to "flow" providing you with backwards compatible updates during its supported life.
You may be thinking to yourself, this sounds a lot like the promise of the Red Hat Software Collections (RHSCL) components and, it is similar. However, with Software Collections (SCLs):
- the application is installed in a non-standard location
- the name of the SCL must be unique and indicate what it is leading to complicated names
- the collection must be enabled for every process that wishes to use it
Application Streams on the other hand, install to the normal on disk locations and have distinct metadata to provide information about what is available in the stream. Application Streams are typically named for the version of the software that is included, e.g. nodejs:8 or nodejs:10, but may use other names like "stable" and "latest" if that makes more sense for that collection of software. The one disadvantage of Application Streams from SCLs is that no two streams can be installed at the same time in to the same userspace. However, in our experience, this is not a common use case and is better served using containerization or virtualization to provide a second userspace.
Hopefully, this overview of the layout of the RHEL 8 Repositories and introduction to AppStreams is useful in providing a high level understanding of the changes with the new version. However, it is worth noting that you can safely ignore everything about AppStreams if you don't need the functionality -- yum install <package> will just work, even if it is coming from an Application Stream, just as it does in RHEL 7.
