The module-build-service

and so can you!

Presented at Flock 2017 by @ralphbean.

Slides available at


in 15 minutes

History of

"how to build modules"

We presented last year at Flock with a barely working prototype.

Since then, nothing has fundamentally changed with respect to the build process. Here are some highlights:

Let's look at these last two in more detail.

Build order


We used to submit a single component build to koji, and then wait for the repo regen to include that build in the buildroot of the next build. Only after waiting for kojira, would we submit the next build. This was insanely slow.

Our approach now takes a hint from the modulemd format. Components may be grouped into build order groups.

All of the components in a single build order group will be built in parallel, without waiting for repo regeneration. Once they're all done, we regenerate the repo and start on the next group.


this module



The original theory was that we can't re-use builds, because the buildroot might have changed.

Our currently implemented approach leverages the build order groups. There's more to it, but in short:

This lets us only rebuild components if there might be significant changes in their build environment.

If the systemtap specfile changed

If the dyninst specfile changed

If the chrpath specfile changed

A review

of MBS internals

Primarilly composed of two processes:

The web


The web frontend responds to queries about the status of modules. it also receives requests to build new modules.

Upon receipt of a request to build, the frontend:

The backend then picks up the messages about the new request and, if it is idle, it starts processing it.

module build


Module builds move through a series of states as they are built:

All the work happens in the build state.

Build steps

in koji

First, let's distinguish between the different Builder backends. We currently have code to build in local mock, in a remote koji instance, or in a remote copr instance.

(1.0) build tags are created for the module (build and dist).

(1.1) Importantly, the build tag inherits from other modules that the module declares build-time deps on.

(1.2) Furthermore, the build and srpm-build groups are defined based on profiles of those dependencies.

(2.0) Then, a module-build-macros srpm is synthesized and built.

(3.0) Finally, the rpms in the module are built in a series of "buildorder groups" (remember from earlier?).

How is this


A word

about local builds

You can build modules locally with the mbs-build local command.

That process is an instance of the mbs backend schedular (with the local mock builder plugin enabled). The same process running in the production environment.


Things we're working on in the near future.

Thank you

The module-build-service is written by: Jan Kaluza, Ralph Bean, Filip Valder, Jakub Kadlčík, Matt Prahl, Lubos Kocman, Petr Šabata, Nils Philippsen, Karsten Hopp, Stanislav Ochotnicky, Tomas Tomecek, Neha Prasad, Courtney Pacheco, Owen W. Taylor, Matt Jia, Yashvardhan Nanavati, Patrick Uiterwijk, and James Antill.

@asamalik will pick it up next on "Packaging Modularity".

Slides available at

Right, Down, Page DownNext slide
Left, Up, Page UpPrevious slide
POpen presenter console
HToggle this help