From Fedora Project Wiki

< Modularity

Revision as of 21:35, 7 May 2018 by Merlinm (talk | contribs) (supply details for requesting a module dist-git repository)

The process

The process has four main steps:

new repositories --> build it --> add it to the release --> set / change the default

Step 1: new repositories

This step includes creating new repositories or branches in dist-git for both RPM packages and modules.

Overview

Packages should be handled the same way as they are now. That means:

  • When adding a new package (creating a new dist-git repository), the package goes through the Package Review Process. This is to check the compliance with the Fedora Packaging Guidelines.
  • When adding a new branch to an existing package, no formal review is necessary.

Repositories and branches for modules should not require any review. This is because:

  • At this point, modules are not included in any release.
  • Modules themselves do not provide any content. New content is provided by packages that need to pass a review.

Of course, to request any repositories in the dist-git, one needs to be a Fedora packager.

What to do

Packages: Follow the Package Review Process for Contributors.

Modules: If your module is to be named the same as an existing package, requesting a stream branch for the package using the fedpkg request-branch command will automatically also request a corresponding module dist-git repository unless the "--no-auto-module" option is supplied. Otherwise, use the fedpkg --module-name modules/_name_ request-repo --exception command.

Step 2: build it

Overview

This step is about submitting a module build to the Fedora infrastructure. The resulting binaries will not be included in any release in this step. Anyone who is a Fedora packager should be able to build modules they own. There is no review or approval at this point.

What to do

Use the fedpkg module-build command inside your local copy of the module dist-git repository.

Step 3: add it to the release

Overview

In order to make a module available to the end user, it needs to be released. Technically, this means including the module in a compose.

No review is done at this point, as all the software that is being added already passed the Package Review Process.

What to do

Add your module builds to an update in Bodhi. Use the builds field as Bodhi doesn't yet support searching for modules by name.

Please note that it might take about a day for your module to show up in updates-testing.

Step 4: set / change the default

Overview

Setting or changing a default stream or a default installation profile of a module is in most cases similar to changing a major version of a package. Setting or changing the default stream or the default installation profile requires a Fedora Change request, and it is only allowed in between Fedora releases.

What to do

Submit an issue to Fedora Releng in pagure.io/releng. You also need to submit a Fedora Change

To check the current defaults, have a look at the fedora module defaults repository.

Setting or changing default stream of a module will be considered based on the following rules:

  • If the module stream does not mask any part of the Traditional RPM repos, it may be set as a default stream. For example, any module that is entirely a leaf or one that fulfills the function of a package moved from the traditional repos into the modular repos (e.g. nodejs:8 might replace the nodejs traditional package)
  • If the module stream masks part of the Traditional RPM repos (e.g it replaces an existing RPM or it introduces a non-trivial set of conflicts) it may not be made a default stream without the express permission of FESCo. Release engineering will be responsible for escalating any PR that is questionable on this point to FESCo for a final decision.