Policies Regarding Modules in Fedora, Fedora ELN and EPEL

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 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.[3]

  • 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.[4]

  • 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.[5]

  • The default stream of a module MUST NOT change to a different stream within a released Fedora version.[6] 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.[7]

  • 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.[8]

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

  • 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.[10]

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. It is highly recommended that default streams have no module dependencies besides the platform to avoid potential future conflicts during upgrades.
4. 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.
5. 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.
6. This is an extension of the stable updates policy.
7. Modular packages shadow non-modular ones. This rule ensures that we don’t have any shadowed packages in the default package set.
8. In this situation, whichever has the highest NEVRA would win the depsolving and could break the other module.
9. 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.
10. 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.