Language and Page Formatting Options
Chapter 11. 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 11.1. "Modular dependencies and stream changes" describes modular dependency rules.
- Section 11.2. "Interaction of modular and non-modular dependencies" provides details for how the dependencies of module streams affect handling of package dependencies.
- Section 11.3. "Resetting module streams" provides steps for resetting modules to their initial state.
- Section 11.4. "Disabling all streams of a module" provides steps for completely disabling a module and all its 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.
As a result:
- Enabling a module stream can require enabling further module streams.
- Installing a module stream profile or installing packages from a stream can require enabling further module streams and installing further packages.
- Disabling a module stream 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 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 all of its streams to their initial state - neither enabled nor disabled. If the module has a configured default stream, that stream becomes active as a result of resetting the module.
The following procedure describes how to reset a module stream to the initial state using
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. In situations where the content from all the module streams should not be accessible, it is possible to disable the whole module.
The following procedure describes how to disable all streams of a module using
- You understand the concept of an active module stream.
Disable the module:
# dnf module disable module-name
dnfasks for confirmation and then disables the module with all its streams. All of the module streams become inactive. No installed content is removed.