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.

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 yum 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 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 yum.

Procedure

  • 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.

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 yum.

Prerequisites

Procedure

  • Disable the module:

    # yum module disable module-name

    yum asks for confirmation and then disables the module with all its streams. All of the module streams become inactive. No installed content is removed.