Module Artifacts

Artifacts are consumable outputs of the build and release processes e.g. an ISO image, an RPM repository, a container base image, or an OSTree tree.

The artifacts of a module stream are a modulemd YAML file and the source and binary RPM files. Each component of a module stream represents a RPM package. All the built source and binary RPM files are recorded in the artifacts section of a output modulemd YAML file. We are reusing packages as they are. Packages are the smallest unit of software delivery. Fedora uses RPM packages to build and ship all of its software. There is a distinction between source RPM (SRPM) packages and binary RPM packages.

As the name suggests, source packages contain the source code, but also the build process definition including a list of build dependencies. Building a source package results in one or multiple binary packages.

Binary packages are produced by building source packages in a build environment called a buildroot. Different buildroots produce different binary packages. This means that a source package without a context is not a complete definition of a resulting binary package.

Module streams are delivered as an RPM repository that will work on top of existing releases. The modular repository will also be available in the Fedora container base image, enabling users to build containers with multiple versions of software.

Failsafe

Artifacts which are the result of a module stream build are ordinary source and binary RPM files. There is one difference. Each binary RPM package built within a module stream contains a modularitylabel flag inside its file header. This flag is set during the build process of a RPM package. We need this to be able to distinguish between the binary RPM files built within a module stream and RPM files built the non-modular way.

We also refer to RPM artifacts built within a modules stream as module (or modular) RPMs.

The modularitylabel flag is an important feature of modularity. Module RPM artifacts can not be installed by themselves. If a modularitylabel flag is detected in the header of a RPM file the installation will be rejected. This is also called a failsafe. Module streams need to be enabled first by DNF and then the RPM packages within a module stream will be available for installation. The failsafe guarantees that the correct RPM packages are visible and available for installation and all necessary modular dependencies are satisfied before the DNF transaction can proceed. All this information is stored in the modulemd YAML file. Without this file DNF does not know which RPM package should be installed and what is their relation with the rest of the RPM repository.

Compatibility

As we already established earlier, module streams are only bundles of RPM packages which are installed together. This means that existing non-modular RPM packages can be bundled into a module stream just with adding the correct modulemd YAML file to the repodata.

We strongly discourage you to create module streams out of non-modular binary RPM as this can cause wrong dependency resolution of your installation transaction and break your system. Alway build your module streams through a distribution pipeline or local cli tools.

Want to help? Learn how to contribute to Fedora Docs ›