Building Software with Modularity

This is a high-level overview of how builds work with Fedora Modularity and how it compares with traditional builds.

Traditional package builds

mod doc trad builds

In the existing Fedora world, packages are maintained in branches that map to specific Fedora releases. Package repositories have branches e.g. “f27” for Fedora 27, “f28” for Fedora 28, etc.

There are no changes to the existing packager workflow. Maintaining release-specific branches and using the existing commands to build them will keep working.

Modular package builds

mod doc stream builds

Modularity changes package branching to be version-focused.

Branching packages according to their major version as opposed to the distribution release brings more clarity — because we can see what lives in a branch, and removes source duplication — because there is one branch per version.

While this approach makes more sense from the software perspective, there is no longer a clear mapping of a package branch to a particular release. Modules are a way of defining this.

Building one source for multiple releases

mod doc build more releases

Modules define what package branches are built for which Fedora releases. One module can be built for multiple releases.

The above example produces three different binaries, one for each release. In case there are multiple architectures, three binaries will be produced (one each).

Building multiple versions

mod doc build more versions

Multiple versions of packages can be built for one release by defining multiple modules. Users are able to choose which version they want to use on their system.

The above example produces two different binaries, each with a different Python version. Again, in case there are multiple architectures, two binaries will be produced for each one.

Modularity also leverages existing technologies such as containers to enable users to run multiple versions at the same time on one "machine."

Building against multiple versions

mod doc build matrix

Modules can be also be built against other modules to achieve more complex results. Client tooling always makes sure the right version is installed for a given context.

The above example produces two different binaries, each bound to a different Python version. Again, in case there are multiple architectures, two binaries will be produced for each one.