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.


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



  • Disable the module:

    # dnf module disable <module-name>

    The dnf command 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.


  • The system is fully updated.


  1. 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:18 module stream to the nodejs:20 stream, enter:

    # dnf module switch-to nodejs:20
    Dependencies resolved.
     Package          Arch   Version                                   Repository      Size
     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-
                                                                       rhel-AppStream 2.6 M
    Switching module streams:
     nodejs                  18 -> 20

    You 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
     php-common   x86_64   8.1.14-1.module+el9.2.0+17911+b059dfc2    rhel-AppStream   687 k
    Enabling module streams:
     php                   8.1
  2. Optional: 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>


  • Verify that the installed component was switched to the new version ([e]):

    $ dnf module list nodejs
    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