Policies Regarding Modules in Fedora, Fedora ELN and EPEL
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]
dnf install package
are fully supported as any non-modular package.
alternatives
system or virtual Provides
for capabilities.
Want to help? Learn how to contribute to Fedora Docs ›