Changes/Module Context Upgrade Paths

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Module Context Upgrade Paths

Summary

Modularity doesn't define any upgrade paths among module Contexts. Fix that by introducing following changes:

• Change NSVCA module identifier to NSCVA; NSC will define a group of packages that belong together (a "repository")
• Enabling a Stream will resolve a module transaction and store information about
• Change stream expansion so related module builds always end up with the same Context
• Use only the latest Version of a module to compute module Stream dependencies
• Allow Context to be human-readable rather than the current hash (Context is close to the %{?dist} macro)
• Drop explicit runtime dependency on platform ($releasever should be good enough)

Owner

• Name: Daniel Mach
• Email: dmach@redhat.com

Current status

• Targeted release: Fedora 34
• Last updated: 2020-06-25
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Modules are identified with N:S:V:C:A identifier. This ID doesn't explicitly determine how the related modules should be grouped together and ordered to enable upgrade paths among them.

This has several consequences:

• Modules are difficult to work with, the relations are not obvious at the first sight.
• DNF literally guesses the upgrade paths by resolving a transaction for each module version and it frequently fails to find a solution.

Benefit to Fedora

• Allow stream dependency changes (remember libgit2 problem?).
• Make modularity less complex and easier to understand for end-users, sysadmins, and also packagers.
• DNF will not error out on module dependency problems that frequently.

Scope

• Proposal owners:
  • Create modulemd v3 document that supports the new stream expansion.
  • Work with libmodulemd upstream to implement modulemd v3.
  • Work with MBS developers to implement the new stream expansion.

• Other developers:
  • Change modulemd sources to explicitly list contexts to be expanded by MBS

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)

• Policies and guidelines: N/A (not a System Wide Change)

• Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

• A module dependency change in a Stream must work.
  • example:
    • n:s:c:1:x86_64 requires nodejs:10
    • n:s:c:2:x86_64 requires nodejs:12
• Context gaps no longer cause module dependency problems.
  • example:
    • n:s:pl528:1:x86_64 requires perl:5.28
    • there's no context for perl:5.30 in version 1
    • n:s:pl528:2:x86_64 requires perl:5.28
    • n:s:pl530:2:x86_64 requires perl:5.30
    • there's no context for perl:5.28 in version 3
    • n:s:pl530:3:x86_64 requires perl:5.30

User Experience

Users will not experience modularity issues in DNF that frequently.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No
• Blocks product? product

Documentation

Changes to modularity documentation will be made during implementing this Change.