Red Hat SummitIl blog di Red Hat
Many have noticed a general lack of modules in Red Hat Enterprise Linux (RHEL) 9. There was only a single module in the Beta release, and none in the initial release, leading many to question the current status and plans for modules in general.
In this article we will delve into a bit of history as to how modules have been used, some of the lessons learned during their initial adoption, and what you can expect from RHEL 9.
Application streams
With RHEL 8, a new concept was introduced in the form of application streams. A common use-case for application streams is to allow the introduction of newer versions of popular applications at a faster pace than had been seen previously with RHEL releases. These are introduced as new streams that are supported for a predefined period of time.
[Read more: Red Hat Enterprise Linux 8 Application Streams Life Cycle - Red Hat Customer Portal]
This type of application stream release has led many to infer that modules are one and the same. In actuality, modules are a packaging format technology. They are just one of the forms that application streams can take, as there are quite a few others, including:
- Traditional RPMs
- Modules
- Flatpaks
- Software Collections
The packaging format selected for a given application stream is selected primarily based on the best fit for the component, the duration of support and upstream community plans.
Modules are used when they are the best technology for the job. If another format is more beneficial, that is the format used.
Modules
As mentioned above, a common need is to allow different application streams to be supported for overlapping periods of time. In the traditional RPM case, this is difficult to achieve as the newest version will be selected. That must be avoided as many major versions of software are not inherently backwards compatible. In the event that a database was updated between major versions during a routine update, it could mean an outage, or worse.
With RHEL 7, the format preferred was software collections (SCL). If you needed to install multiple versions at the same time, these were excellent. If you wanted to select a specific version to be the only one installed, they could be suboptimal.
When you do not need multiple versions installed or running at the same time, modules are ideal. By building specific major versions of software together as a module, and enhancing the package management tooling to understand these, multiple versions are simultaneously available and end users could select which version they needed while maintaining system updates. No need to use “scl enable” commands as the version used is selected at installation time!
This leads to some questions.
Why are there so few modules in RHEL 9?
The response from customers has been overwhelmingly positive regarding application streams, yet there are always improvements to be made. One of the improvements identified early was to identify the full life streams (the same life cycle as RHEL 9) as early as possible, allowing customers to incorporate this type of low-level planning information into their adoption plans much earlier in the release.
Another improvement was driven by the desire to have a simple distinction between which versions would be supported for the full life of the RHEL release, versus those that would be supported for a shorter duration.
To meet this need, wherever possible, a particular version is being identified as the full life version of an application for initial release. The second improvement being that this version is being released as a traditional RPM as opposed to a module. This means that users and developers that choose to rely solely on these full life application streams can omit module-specific tooling and processes.
Will there ever be modules in RHEL 9?
Yes. Going forward, as additional major versions of application streams are identified as necessary, subsequent RHEL 9 releases will release additional application streams with shorter support durations. In the event that there is an overlap and conflict between versions, modules will be the mechanism used when it is the best fit for the application.
How does that work?
RHEL 9 will not include any default module streams. Without being enabled, module streams supersede traditional RPMs. So by releasing a single stream as traditional RPMs, but offering modular streams at a later date, you end up with the best of both worlds.
The traditional RPM version will be used when not specifically enabled otherwise, easing the user experience by further simplifying the package management process.
Continually improving
With RHEL 9 we have improved the module user experience based on our experience with software collections, modules in RHEL 8, and feedback from our customers.
