The RHEL distribution is based on rpm packages. Each major RHEL distribution is supported for 10 years.
During the 10 years, the kernel/glibc parts can’t really evolve a lot: bugs are fixed but only minor features are added due to maintenance constraints.
During the 10 years, the development tools evolve a lot (new versions of PHP, Java, etc).
In fact, there are two different lifecycles: one for the operating system and one for the rest (development tools, languages, applications, etc).
To solve this problem in RHEL 6 & 7, RedHat created the Software Collections (SCL). This solution was not satisfying and Red Hat searched for another option via tests in Fedora, the test-bed/cuting-edge Red Hat distribution.
Finally, it was decided to create three application streams, each one with its own lifecycle:
- BaseOS provides the foundation of the operating system,
- AppStream supplies all the user applications,
- CodeReady Linux Builder provides developer tools and languages.
Due to the philosophy changes, EPEL 7 is not compatible with RHEL 8.
Modules are the mechanism of delivering multiple streams (versions) of software within a major release or a single stream across multiple releases.
Modules are collections of packages representing a logical unit e.g. an application, a language stack, a database, or a set of tools. These packages are built, tested, and released together.
Each module defines its own lifecycle which is closer to the natural life of the application rather than the RHEL lifecycle. Each stream provides one or several installation profiles (client, server, etc).
There are always available defaults: user can choose a specific version only when he wants to. Updates will respect user’s choice and won’t upgrade to a different stream.
Differences between RHEL 7 and RHEL 8
There were numerous repositories with RHEL 7. In RHEL 8, this number has been seriously reduced.
RHEL 8 BaseOS and AppStream
Two main repositories:
- The BaseOS repository mainly concerns the operating system.
- The AppStream repository contains application modules and non-modular RPMs.
Module Stream Expansion
Stream Expansion allows for automatic submission of multiple builds of the same component based on multiple versions of its build dependencies.
One module can be built against multiple RHEL releases, or against multiple streams of other modules such as language runtimes, producing a matrix of binaries for all defined combinations.
These are the same modules of the same stream, but of a different context.
Source: Fedora website.