Submitting module builds in Fedora

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

Module builds are triggered using fedpkg from within your dist-git repository.

$ fedpkg clone modules/NAME
$ cd NAME
$ fedpkg switch-branch BRANCH
$ fedpkg module-build

  • NAME — name of the module

  • BRANCH — name of the stream branch of the module

Please note the module build ID. You will need it to verify the build state and to publish the module later.

To watch the state of your module build, run:

$ fedpkg module-build-watch BUILD_ID

When the module is in a "ready" state, the build has successfully completed.

You can also watch the build(s) on Fedora Module build service:

https://release-engineering.github.io/mbs-ui/modules

Module build results

All the packages built in the module are tagged in Koji tag named as module-$name-$stream-$version-$context. The link to this tag is also available in Fedora Module build service UI mentioned earlier.

There are also two Koji Builds representing single module build.

  • $name-$stream-$version.$context - Contains the metadata with final RPMs which will be included in a compose and will be therefore visible by the end user.

  • $name-devel-$stream-$version.$context - Contains the metadata with filtered RPMs which are not normally visible to end user, but might be sometimes useful when building other packages against the module. Generally, in Fedora we do not ship the -devel modules.

You will not find $name-devel module build in Module Build Service, because this is only another representation of non-devel module build. It is not separate module build on its own and it only exists as Koji build.

Both Koji module builds contains various metadata files:

  • modulemd.src.txt - The unchanged input modulemd metadata used to build a module as stored in dist-git.

  • modulemd.txt - The expanded modulemd metadata which was used by Module Build Service to build this particular module. This for example contains the right build requirements based on the Module Stream Expansion.

  • modulemd.$arch.txt - The per-architecture modulemd metadata listing the RPMs which will end up in a compose and therefore be visible to end user. This for example respects filters or multilib modulemd options.

Rebuild strategies

In case you want to control which packages get rebuilt and which get reused, you can enforce a specific rebuild strategy while submitting a build.

There are different rebuild strategies to choose from:

  • all — All packages in the module get rebuilt.

  • only-changed — Only packages that have changed since the last successful build get rebuilt. This is the default in Fedora.

  • changed-and-after — This one leverages build groups (buildorder). Packages that have changed since the last successful build get rebuilt, and also all packages with a buildorder higher than any of the changed ones get rebuilt as well.

To enforce a specific rebuild strategy, submit the module build with the following command:

$ fedpkg module-build --optional rebuild_strategy=STRATEGY

  • STRATEGY — name of a specific build strategy (listed above)