Main Concepts of Modularity

We are reusing packages as they are.

Packages are the smallest unit of software delivery. Right now, 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.

Every Fedora release has its own buildroot. Even when multiple releases contain the same package using the same source, they are built multiple times, once in each buildroot, producing different (and often incompatible) binary packages. Also, over time, as the distribution gets updated, so does its buildroot. As a result, a package built today may not result in the same binary as a package built tomorrow.

Packages are either a part of a release, or a part a module.

Releases are the generations of Fedora e.g. “Fedora 28”, “Fedora 29”, or “epel 7”.

Each release can only contain one major version of every package (by policy). In general, Fedora tends to ship the latest stable versions of software available. At the same time, packages need to maintain a certain API/ABI stability throughout the lifecycle of the release they are part of.

The problem with this approach is finding the right balance of being too fast vs. too slow. For example, developers in general tend to prefer the newest versions of software, while server administrators want API/ABI stability for a longer period of time. This problem is solved by Modules.

Modules are collections of packages representing a logical unit e.g. an application, a language stack, a set of tools. These packages are built, tested, and released together.

Each module defines its own lifecycle which is closer to the upstream rather than the Fedora release.

Modules are the mechanism of delivering multiple streams (versions) of software for the same release. This also works the other way round, the same stream for multiple releases.

A stream is a series of versions having a goal such as backwards API/ABI compatibility or delivering the latest stable version. A “nodejs” interpreter can have streams such as 6 or 8 (two current versions of nodejs), but also “devel” or “latest”. Some packages don’t have a major version. An example could be the “calc” package that is being developed in two branches “stable” and “unstable”.

Simply put, streams are the mechanism of delivering and updating software at different speeds, allowing developers to have bleeding-edge software, and server admins longer stability.

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.

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