Edit

Main Concepts

Modularity reuses some existing and creates some new concepts of the build and release process in Fedora.

Packages

../_images/mod-doc-package.png

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 package is produced by building a source package in a build environment called 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.

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

Releases

../_images/mod-doc-release.png

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

Each release can only contain one major version of every package. 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 and Streams

../_images/mod-doc-module.png

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.

../_images/mod-doc-stream.png

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”, 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 a bleeding-edge software, and server admins longer stability.

Artifacts

../_images/mod-doc-artifact.png

Artifacts are consumable outputs of the build and release process e.g. an iso image, an RPM repository, a container base image, or an ostree tree.

Each release has associated multiple artifacts with it e.g. Fedora 28 install DVD, Fedora 28 updates repository, etc.

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.