From Fedora Project Wiki

Objective: Modularity Improvements (2020)


Plans for Fedora 33 and 34 are to improve the existing implementation of Modularity. We may look into alternatives or bigger design changes in Fedora 35 and later.


The current implementation of Modularity landed in Fedora 29. There were identified gaps that impact user experience. Even though there have been several fixes and improvements, there is still a lot to do. A new team started to own the Modularity project at Red Hat in February 2020. The team has posted a survey and the feedback identified many gaps, especially from the packagers’ point of view.


According to the survey, the team identified priorities for the next 12-18 months:

  1. Maintain Modularity to be available for any projects under the Fedora Project umbrella (Fedora packages, SIGs, Spins, etc., including EPEL) and enable modules to provide alternative streams with different lifecycles.
  2. Improve tools to create and maintain modules, which includes
    • Update and extend the tools for building modules on local host
    • Work with developers of the tools used in the Fedora infrastructure to support Modularity in their tools
  3. Improve documentation and guidelines for users and packagers, based on the feedback from the survey.
    • Work with Fedora users and packagers to ensure that we have answers for problems arising in practice
  4. Consider deeper architectural changes in Modularity. We expect to start working on this goal in spring 2021.


  • Fedora 33
    • Improve documentation and guidelines for users and packagers
    • Implement low-level tools for building modules locally and managing (editing, creating) modulemd data locally
    • Implement the Module Obsoletes and EOL Change to fix system upgrades
  • Fedora 34
    • Implement the Module Context Upgrade Paths Change
    • Implement module stream switching
    • Stretch goal: Improve querying module RPMs
    • Implement tools for downloading individual modules from repositories
    • Implement tools for creating and managing repositories with modules

Objective Lead

  • Daniel Mach <>

Objective Implementation Team

  • Martin Curlej - modularity generalist, knows a bit about MBS
  • Jaroslav Mracek - DNF
  • Ales Matej - DNF, libmodulemd
  • Jakub Kadlcik (FrostyX) - helping with low-level tools, possibly some mock/COPR integration