Adding new modules to Fedora

This page will guide you through the whole process of adding a new module to Fedora:

  1. RPM Sources — To dist-git/rpms using stream branches.

  2. Module Definition — To dist-git/modules using stream branches.

  3. Module Build — Module is built as a unit. No individual package builds are done.

  4. Publishing the Module — Submitting a Bodhi update.

RPM Sources

For each package in your module, you need to have a Fedora Distribution Git (dist-git) repository under dist-git/rpms with an appropriate stream branch. New packages need to go through a package review.

Repositories and Stream Branches — New packages

The Fedora Package Review Process covers all the steps you need to take, except for stream branches. For that, please continue below to Existing packages.

Repositories and Stream Branches — Existing packages

Requesting new stream branches for existing packages is done with fedpkg, and it doesn’t require a package review.

To create a new branch for a package that shares a name with the module (e.g. "postgresql"), run the following command which will create the package stream branch as well as the module and its stream branch together:

$ fedpkg request-branch --repo=NAME --sl rawhide:2020-12-01 -- BRANCH

  • NAME — name of the package and the module

  • BRANCH — name of the stream branch of the package and the module

  • rawhide:2020-12-01 — expected end of life, must end with either 12-01 or 06-01. Right now, this is not actively used to do anything useful, although some systems might block you from maintaining your module. Please choose a date far in the future so you’re not affected. [Work to fix this is in progress](https://tree.taiga.io/project/modularity-wg/epic/3).

If this package does not share a name with the module (such as for dependencies), then only request the stream branch for this package:

$ fedpkg request-branch --repo=NAME --no-auto-module --sl rawhide:2020-12-01 -- BRANCH

  • --no-auto-module — Skip the creation of a module of the same name

Creation of the module and its stream branches separately will be covered later.

Importing the RPM sources into dist-git

The last thing to do is to import the RPM sources into dist-git. Please refer to the New package process for existing contributors for the complete steps.

Module Definition

For your module definition, you also need to have a dist-git repository, this time under dist-git/modules, with an appropriate stream branch.

Repositories and Stream Branches — New modules

To request a new module repository in dist-git run:

$ fedpkg request-repo --namespace modules --exception NAME
$ fedpkg request-branch --namespace modules --repo NAME BRANCH

  • NAME — name of the module

  • BRANCH — name of the stream branch of the module

Repositories and Stream Branches — Existing modules

to request a new stream branch, run:

$ fedpkg request-branch --namespace modules --repo NAME BRANCH

  • NAME — name of the module

  • BRANCH — name of the stream branch of the module

Write and push the modulemd

Writing a modulemd is covered in detail in the Defining Modules in modulemd section.

The name of the modulemd must match the name of the repository. Remember to replace every NAME in the following example. 
$ fedpkg clone modules/NAME
$ cd NAME
$ fedpkg switch-branch BRANCH
$ vim NAME.yaml
$ git add NAME.yaml
$ git commit -m "add the initial modulemd"
$ git push

  • NAME — name of the module

  • BRANCH — name of the stream branch of the module

Module Build

NOTE: With Modularity, you no longer build individual packages. Instead, you need to submit a module build.

Submitting module builds is done using fedpkg and is covered in the Building modules section.

Publishing the Module

To make your module available to users, submit submit as an update to Fedora Bodhi. Make sure you are logged in, and then click on Create / New Update at the top-right corner. Fill out the following fields:

  • Candidate Builds: MODULE_BUILD_ID

  • Update notes: notes for the users

  • Final details: check what applies

One way of getting the MODULE_BUILD_ID is running the same command as in the previous step:

$ fedpkg module-build-info BUILD_ID

and changing the "koji tag" value in the following way:

module-nodejs-10-20180607142235-6c81f848   <- koji tag
       nodejs-10-20180607142235.6c81f848   <- MODULE_BUILD_ID

that is removing the "module-" part at the beginning, and replacing the last "-" with a ".".