Module Obsoletes

Module Obsoletes in the Pipeline (Quick Start)

  1. Add obsoletes in the module-defaults repository.

  2. Configure pungi to use the obsoletes and create a modular compose using pungi.

  3. The obsoletes metadata will appear in the modules.yaml file of the resulting repodata.

Individual Steps

Prepare module obsoletes metadata

Follow the module obsoletes specification for an up-to-date format. As of the time of writing this article (January 2022), there’s been v1 specification available and supported in the pipeline.

Examples:

  1. EOLed stream nodejs:11 as of a specified date/time

    document: modulemd-obsoletes
version: 1
data:
  modified: 2018-05-23T14:25Z
  module: nodejs
  stream: "11"
  # A string representing UTC date in ISO 8601 format: YYYY-MM-DDTHH:MMZ
  # It is strongly recommended to keep HH:MM to 00:00.
  # If not specified, the module is EOLed immediately.
  # OPTIONAL
  eol_date: 2020-03-19T00:00Z
  message: "Module stream nodejs:11 is no longer supported."

  2. Immediately obsoleted stream nodejs:11 with a new stream nodejs:12 available

    document: modulemd-obsoletes
version: 1
data:
  modified: 2018-05-23T14:25Z
  module: nodejs
  stream: "11"
  message: "Module stream nodejs:11 is no longer supported. Please switch to nodejs:12"
  obsoleted_by:
    module: nodejs
    stream: "12"

Theses are perhaps the most common scanarios, but check the specification for other workflows:

  • Resetting a previously EOLed/obsoleted stream.

  • Obsoleting/EOLing a specific module stream context.

Add the metadata into fedora-module-defaults.git repository

  1. Clone the repository and add the module obsoletes metadata into the obsoletes/ directory.

    Use <name>:<stream>.yaml convention as each file can contain only a single module obsoletes document for the subsequent processing to be successful.

    Make sure to commit your changes before going to the next step.

  2. Execute run_tests.sh in the root of the repository to validate the metadata locally.

    First, testing metadata are checked to make sure your libmodulemd is able to handle module obsoletes. Then the actual metadata in the obsoletes/ directory are validated.

  3. After a successful validation, file a pull request for the module obsolete to be included in the repository. Use branch main for including module obsoletes into Fedora Rawhide. Check fedora-module-defaults repository for all the branches.

Configure pungi for module obsoletes and create a modular compose

  1. Add the following snippet to pungi configuration.

        # Optional module obsoletes configuration which is merged
    # into the module index and gets resolved
    module_obsoletes_dir = {
        'scm': 'git',
        'repo': 'https://pagure.io/releng/fedora-module-defaults.git',
        'branch': 'main',  # main for Rawhide, otherwise must match the fedora-module-defaults branch
        'dir': 'obsoletes'
    }
    Check pungi-fedora for all the branches.

  2. Follow pungi docs on how to create a modular compose.

    Check the gathering phase of a modular compose and the corresponding configuration reference.

Final repodata contain module obsoletes

There are several paths how module obsoletes can appear in the compose metadata:

  1. Forward: Just follow the steps above and wait for a next modular compose of Fedora Rawhide to appear.

  2. Backward (backporting): Since the module obsoletes are checked within any modular compose build, you may wait for some other module’s update to push the changes through. This can be an issue in case of an already EOLed/dead module. Again, follow the steps above and contact releng team requesting manual modular compose build.

When the obsoletes metadata appear in the repodata (modules.yaml file), DNF is expected to handle the information regarding obsoletes and react accordingly.

If in doubt, check https://github.com/rpm-software-management/ci-dnf-stack/blob/master/dnf-behave-tests/dnf/module/obsoletes.feature for what’s the expected behavior.

Want to help? Learn how to contribute to Fedora Docs ›