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.

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, you must first reset the module, and then enable the new stream. Removing all packages installed from a stream before switching to a different stream is highly recommended, because it 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.

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.

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.

Procedure

  • Reset the module state:

    # yum module reset module-name

    All streams of the module are returned to the initial state. No installed content is removed.

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.

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.

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

  • The system is fully updated.

  • No packages installed on the system are newer than the packages available in the repository.

Procedure

  1. 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, refuse these changes and modify your system to a state where the command completes with no further action required.

    By checking the yum distro-sync result 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.

  2. Change the active stream to the later one:

    # yum module reset module-name
# yum module enable module-name:new-stream

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

    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 --allowerasing option to remove such packages because they cannot be installed together with the later stream due to missing dependencies.

    When switching Perl modules, the --allowerasing option is always required because certain packages in the base CentOS 8 installation depend on Perl 5.26.

Alternatively, remove all the module’s content installed from the current stream, reset the module, and install the new stream.

Additional resources