Consuming Software with Modularity

This is a high-level overview of how users can install software with Fedora Modularity and how is it different from the traditional workflow(s).

Understanding the Delivery Channels

Modular Fedora will ship with two sets of repositories:

  1. The traditional base repository representing the distribution as we know it today — there are no user-visible changes in this part.

  2. A new modular repository (often referred to as the "Application Stream" or AppStream for short) including all the additional versions delivered as modules.

The Modules repository will be optional for users.

mod doc repositories

Consuming the traditional packages

There are no changes to the traditional user experience. Packages from the traditional repository will be installed and updated using the same methods as before. Everything keeps working as it used to.

Consuming the modular packages

If a user desires to use the optional Modular repositories in order to consume non-default versions of software, there will be some new concepts introduced in the client tooling to manage them. We outline these below.

Enabling a module

Enabling a module makes its packages available on the system. Packages delivered as part of a module always have a priority over the ones from the traditional base, regardless of their actual version. Packages in modules are often replacements of the ones in the traditional base.

Modularity brings parallel availability, not parallel installability. Only one stream of a given module can be enabled on a system — so it is always clear which version gets installed. Installing and running multiple versions of software can be achieved by using existing technologies, such as containers.

Installing a module

To make installation easy, some modules can be also installed as a unit, without the need of enabling them first and then installing individual packages. Installing a module doesn’t necessarily mean installing all of its packages. Modules can define something called an "installation profile" to help users with the installation.

Installation profile

Installation profiles are essentially lists of packages that help users with the module installation. To give a specific example, a database module could have two profiles: server and client. This helps the user to install what they need without the need of thinking about the package names. However, installation profiles are just an optional feature and users can still install packages directly.

Updating the system

Updating the system always respects user’s module choices (or lack of module) even when there are multiple (and possibly higher) versions available.

If the user doesn’t enable any modules, all packages on their system get updated to the latest versions provided by the traditional base repository. However, if the user enables a module stream, packages get updated to the newest version provided by the module.

Thanks to this mechanism, the user has better control over the versions of packages on their system while receiving updates (such as security patches) for the whole system.

Running multiple versions using containers

Modularity brings parallel availability, not parallel installability. There are other technologies e.g. Linux containers or software collections that deal with this.

All the steps described above can be used in a container the same way as on a traditional system. Producing up-to-date containers with multiple versions of software in an automated way is also one of the goals.