Introduction

Welcome to the Modularity project documentation.

The Modularity project has been created for the purpose of enabling additional versions/flavours of RPM packages in one RPM repository. A standard RPM repository contains RPM packages which are uniquely identified by their name. Of course the package name is not the only package identifier, we have more identifiers (NEVRA) for more granular identification of packages. Basically it was not possible to have multiple RPM packages of the same name in one RPM repository. When we say multiple RPM packages with the same name, we mean RPM packages which are not updates, but RPM packages which are built with different options and features or are built from different source code. 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 life cycle 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. Modularity removes this limitation of a RPM repository with the addition of Module streams.

Modular Repository

In the picture below you can see a classic example of official RPM repositories in the Fedora linux distribution. Fedora Linux is providing one major version of RPM packages for each Fedora release. This is simple view of a “classic” or a non-modular repository.

fedora without modularity

In the following picture we describe a modular repository. A modular repository provides multiple module streams which contain additional RPM packages which can have the same name. A modular repository can still provide RPM packages which are not part of any module but are part of the RPM repository.

fedora with modularity

So in short, Modularity can expand a RPM repository with following features:

  • Module streams add additional packages with the same name, but built from different sources and with different build configurations.

  • Module streams can have different life cycles. For example a package in a distribution can have a different life cycle than the life cycle of the distribution.

  • Module streams can have different installation profiles of its components i. e. you can define one or several module stream profiles which will contain groups of RPMs which should be installed together.

When should you use Modularity?

Any RPM repository can be converted into a modular RPM repository with the inclusion of modular metadata and corresponding binary RPMs. The following points will help you to decide if Modularity can be useful to you.

  • You need/want to provide additional major versions of your existing RPM packages i. e. postgresql 10, postgresql 11 within one Fedora release or a custom RPM repository.

  • You need/want to provide additional custom flavours of your existing RPM packages i. e. custom build RPM packages with a variety of features.

  • You need/want to have different life cycles of your packages in a RPM repository.

  • You are building Flatpaks. RPM package dependencies installed into Flatpak sandoxes are module streams.

  • In general Modularity is a good fit for providing alternative RPM packages for sandbox environments which use RPM based distributions. (Flatpak, linux containers etc.)

Examples

Scenario 1: Some users install packages coming from a different Fedora release in order to consume a specific version of a database that is compatible with their application. But thanks to Modularity they might not need to do that anymore, because multiple versions of the database can be available in each Fedora release. All they need to do is to consume the specific stream of that database right from the Fedora repositories for their system.

Scenario 2: There were cases when users couldn’t upgrade their system to a new Fedora release because their application wouldn’t function with the new version of a language runtime coming with the upgrade. Modularity can fix this problem by providing the same language versions in both Fedora releases. With that, the user can consume a specific stream of the language and keep it even when they upgrade their system. And when the application is ready for the new language version, it can be upgraded later, independently from the OS, by switching to a different stream.

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