Policies Regarding Modules in Fedora, Fedora ELN and EPEL

The Modularity project has been retired and there are no modules in Fedora 39 or newer or in EPEL. This page is only retained for historical reference.

Modularity was retired from Fedora 39+ and EPEL

There are no modules in Fedora 39 or newer. There are no modules in EPEL. The rest of this page serves as a policy for older Fedora releases only (Fedora 37 and 38).

Requirements for All Module Streams

  • The module maintainer MUST have explicit commit privileges to all packages included in the module stream. The provenpackager privilege in Fedora is not sufficient.[1]

  • Components built into a module MUST be associated with a reachable commit in Fedora dist-git.[2]

  • If a stream of a module has build-time-only components, all such components MUST be marked as buildonly: True in the module metadata to avoid shipping them to users and polluting their repository.

Requirements for Modules in Fedora

  • Modular-only packages MUST NOT exist in Fedora. Modular versions MAY exist as alternatives to non-modular packages only. There is an exception to this rule: if the package does not function in non-modular Fedora (with a reasonable amount of work), it is permitted to have it in module only.[3] For the time being, such exceptions can be granted by FESCo.

  • Default streams MUST NOT be used in Fedora.[4]

  • Packagers SHOULD prefer compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability).

Requirements for Default Streams in Fedora ELN

  • Default streams are not permitted in Fedora or EPEL 8. Fedora ELN permits defaults streams that adhere to the policy below.

  • All RPMs in default module streams are required to conform to the same requirements around Conflicts as non-modular RPMs.

  • Packages provided at runtime by the default stream of a module MUST depend only on packages provided by packages from default module streams or the non-modular package set. By extension, default streams of a module MUST NOT have a dependency on any non-default stream.[5]

  • Packages provided from default streams MAY depend on content from other default streams. If they do so, this dependency MUST be encoded in the module metadata.[6]

  • All packages provided at runtime by the default stream of a module MUST provide all the same functionality that a downstream consumer would expect from a package in the non-modular package set.[7]

  • All packages provided at runtime by the default stream of a module SHOULD be declared as a module API or bundled appropriately.[8]

  • The default stream of a module MUST NOT change to a different stream within a released Fedora version.[9] The default stream MAY be changed in Rawhide or during Fedora upgrades. Changes to default streams MUST be approved via a Fedora Change proposal.

  • Packages MAY convert from a non-modular package to a modular default stream (or the reverse) only in Rawhide or during Fedora upgrades.

  • Default streams MUST NOT provide a binary RPM with the same package name as a non-modular RPM in the same release except in the case of a transition from one to the other.[10]

  • Default streams MUST NOT provide a binary RPM with the same package name as an RPM in a default stream of another module in the same release.[11]

  • Multiple default streams MUST NOT provide the same binary package names at runtime.[12]

  • Default streams MUST NOT provide a package that overrides a package of the same name in the non-modular content except in approved cases of migration between modular and non-modular delivery.

  • Default streams MUST NOT use the data.buildopts.rpm.macros metadata section without approval by FESCo.[13]

1. This ensures that the package in the module is being maintained by someone responsible for it.
2. There are legal and licensing requirements for reproducibility of builds.
3. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora.
4. This rule may be revised in the future, especially if the functionality of default streams is improved.
5. It is highly recommended that default streams have no module dependencies besides the platform to avoid potential future conflicts during upgrades.
6. This is so that if the maintainers of either module wishes to change its default stream, it is easy to see what other modules would be impacted and coordinate it.
7. If a package is not filtered out from the default module stream, it is going to be part of the default-available content and therefore must be treated (and supported) just like a non-modular package.
8. This ensures that all packages installable with dnf install package are fully supported as any non-modular package.
9. This is an extension of the stable updates policy.
10. Modular packages shadow non-modular ones. This rule ensures that we don’t have any shadowed packages in the default package set.
11. In this situation, whichever has the highest NEVRA would win the depsolving and could break the other module.
12. They MAY provide other well-known names in the same manner as permitted for non-modular content. For example, two different default streams MAY provide content to be used with the alternatives system or virtual Provides for capabilities.
13. This feature allows for overriding the standard macros for building packages in Fedora and should be avoided entirely for default streams so they are built just like non-modular packages.

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