Chapter 6. Managing versions of Application Stream content
Content in the AppStream repository can be available in multiple versions, corresponding to module streams. This chapter describes the operations you need to perform when changing the enabled module streams in other ways than only enabling new module streams.
- Section 6.1, “Modular dependencies and stream changes” describes modular dependency rules.
- Section 6.2, “Interaction of modular and non-modular dependencies” provides details for how the dependencies of module streams affect handling of package dependencies.
- Section 6.3, “Resetting module streams” provides steps for resetting modules to their initial state.
- Section 6.4, “Disabling all streams of a module” provides steps for disabling completely a module and all its streams.
- Section 6.5, “Switching to a later stream” provides steps for changing to a later stream of a module.
6.1. Modular dependencies and stream changes
Traditionally, packages providing content depend on further packages, and usually specify the desired dependency versions. For packages contained in modules, this mechanism applies as well, but the grouping of packages and their particular versions into modules and streams provides further constraints. Additionally, module streams can declare dependencies on streams of other modules, independent of the packages contained and provided by them.
After any operations with packages or modules, the whole dependency tree of all underlying installed packages must satisfy all the conditions the packages declare. Additionally, all module stream dependencies must be satisfied.
As a result:
- Enabling a module stream can require enabling streams of further modules.
- Installing a module stream profile or installing packages from a stream can require enabling streams of further modules and installing further packages.
- Disabling a stream of a module can require disabling other module streams. No packages will be removed automatically.
- Removing a package can require removing further packages. If these packages were provided by modules, the module streams remain enabled in preparation for further installation, even if no packages from these streams are installed any more. This mirrors the behavior of an unused yum repository.
It is not possible to enable a stream of a module when another stream of the same module is already enabled. To switch streams, follow the procedure in Section 6.5, “Switching to a later stream”. Alternatively, reset the module, and then enable the new stream. Removing all packages installed from a stream before switching to a different stream prevents the system from reaching states where packages could be installed with no repository or stream providing them.
Technically, resetting module does not automatically change any installed packages. Removing the packages provided by the previous stream and any packages that depend on them is an explicit manual operation.
6.2. Interaction of modular and non-modular dependencies
Modular dependencies are an additional layer on top of regular RPM dependencies. Modular dependencies behave similarly to hypothetical dependencies between repositories. This means that installing different packages requires not only resolution of the RPM dependencies, but also the modular dependencies must be resolved beforehand.
The system will always retain the module and stream choices, unless explicitly instructed to change them. A modular package will receive updates contained in the currently enabled stream of the module that provides this package, but will not upgrade to a version contained in a different stream.
6.3. Resetting module streams
Resetting a module is an action that returns all of its streams to their initial state - neither enabled nor disabled. If the module has a default stream, that stream becomes active as a result of resetting the module.
Reset the module state:
# yum module reset module-name
The module is returned to the initial state. Information about an enabled stream and installed profiles is erased but no installed content is removed.
6.4. Disabling all streams of a module
Modules which have a default stream will always have one stream active. In situations where the content from all the module streams should not be accessible, it is possible to disable the whole module.
- You must understand the concept of an active module stream.
Disable the module:
# yum module disable module-name
yumasks for confirmation and then disables the module with all its streams. All of the module streams become inactive. No installed content is removed.
6.5. Switching to a later stream
When you switch to a later module stream, all packages from the module are replaced with their later versions.
This procedure is feasible only under the conditions described below.
- The system is fully updated.
- No packages installed on the system are newer than the packages available in the repository.
Run the following command to determine if your system is prepared for switching to a later stream:
# yum distro-sync
This command must finish with the message Nothing to do. Complete! If it instead proposes changes and asks for confirmation, carefully review these changes, and consider whether you want to proceed. Run the
yum distro-synccommand repeatedly if necessary. Alternatively, you can refuse the suggested changes and manually modify your system to a state where the command returns Nothing to do. Complete!Note
By checking the
yum distro-syncresult before switching the streams, you prevent making changes to the system that are unrelated to the stream switching because the same command is required as the last step of this procedure.
Change the active stream to the later one:
# yum module reset module-name # yum module enable module-name:new-stream
Synchronize installed packages to perform the change between streams:
# yum distro-sync
If this action suggests changes to content outside the streams, review them carefully.Note
If certain installed packages depend on the earlier stream and there is no compatible version in the later stream, yum will report a dependency conflict. In this case, use the
--allowerasingoption to remove such packages because they cannot be installed together with the later stream due to missing dependencies.
When switching Perl modules, the
--allowerasingoption is always required because certain packages in the base RHEL 8 installation depend on Perl 5.26.
Binary extensions (typically written in C or C++) for interpreted languages need to be reinstalled after the new stream is enabled; for example, certain packages installed by the
gemcommand from the
npmcommand from the
cpancommand from the
perlmodule, or the
peclcommand from the
phpmodule. For more information, see How to switch Ruby streams in RHEL 8.
- If certain installed packages depend on the earlier stream and there is no compatible version in the later stream, yum will report a dependency conflict. In this case, use the