Red Hat SummitEste conteúdo não está disponível no idioma selecionado.
Chapter 11. Managing versions of application stream content
Content in the AppStream repository can be available in multiple versions, corresponding to module streams.
11.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 that the packages declare. Additionally, all module stream dependencies must be satisfied. For example, disabling a module stream can require disabling other module streams. No packages will be removed automatically.
Note that the following actions can cause subsequent automatic operations:
- Enabling a module stream can result in enabling further module streams.
- Installing a module stream profile or installing packages from a stream can result in enabling further module streams and installing further packages.
- Removing a package can result in 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 DNF repository.
11.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 resolution of both the RPM dependencies and the modular dependencies.
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.
11.3. Resetting module streams
Resetting a module is an action that returns this module to its initial state - neither enabled nor disabled. If the module has a configured default stream, this stream becomes active as a result of resetting the module.
Resetting the module is useful, for example, if you want to only extract the RPM content from the module without keeping the module enabled. You can use the dnf module reset command after enabling the module and extracting its contents to reset this module to its initial state.
Procedure
Reset the module state:
# dnf 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.
11.4. Disabling all streams of a module
Modules that have a default stream will always have one stream active. If you want to make the content from all module streams of the module inaccessible, you can disable the whole module.
Prerequisites
- You understand the concept of an active module stream.
Procedure
Disable the module:
# dnf module disable <module-name>The
dnfcommand asks for confirmation and then disables the module with all its streams. All of the module streams become inactive. No installed content is removed.
11.5. Switching to a later stream
When you switch to a later module stream, all respective packages are replaced with their later versions.
Back up your data and follow migration instructions specific to the component.
Prerequisites
- The system is fully updated.
Procedure
Switch the installed component to the new version and select the module (component) and stream (version):
# dnf module switch-to <module:stream>For example, to switch from the
nodejs:18module stream to thenodejs:20stream, enter:# dnf module switch-to nodejs:20 ... Dependencies resolved. ======================================================================================== Package Arch Version Repository Size ======================================================================================== Upgrading: nodejs x86_64 1:20.5.1-1.module+el9.3.0+19646+9a702805 rhel-AppStream 14 M nodejs-docs noarch 1:20.5.1-1.module+el9.3.0+19646+9a702805 rhel-AppStream 8.0 M nodejs-full-i18n x86_64 1:20.5.1-1.module+el9.3.0+19646+9a702805 rhel-AppStream 8.5 M npm x86_64 1:9.8.0-1.20.5.1.1.module+el9.3.0+19646+9a702805 rhel-AppStream 2.6 M Switching module streams: nodejs 18 -> 20You can also switch from non-modular content to a module stream. For example, to switch from non-modular PHP 8.0 to modular PHP 8.1, enter:
# dnf module switch-to php:8.1 ... Dependencies resolved. ======================================================================================== Package Arch Version Repository Size ======================================================================================== Upgrading: php-common x86_64 8.1.14-1.module+el9.2.0+17911+b059dfc2 rhel-AppStream 687 k Enabling module streams: php 8.1Optional: Switch the installed component to the new version and select also the profile to be installed or updated:
# dnf module switch-to <module:stream/profile>
Verification
Verify that the installed component was switched to the new version (
[e]):$ dnf module list nodejs ... rhel-AppStream Name Stream Profiles Summary nodejs 18 common [d], development, minimal, s2i Javascript runtime nodejs 20 [e] common [d] [i], development, minimal, s2i Javascript runtime Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
