Introduction
Welcome to the Modularity project documentation.
Modularity can be described as a set of tools that enables you to build your packages in an alternate way to the standard rpm packages. The major feature of Modularity is that it enables you to build multiple major versions of your software for multiple versions of Fedora releases. Modularity is a part of the “packaging ecosystem” that already exists and is used for building rpm packages in the Fedora.
Multiple versions of software
Fedora provides only one supported major version of software per release. This means if you need to use an unsupported version you are on your own, you have to build it yourself or rely on some unofficial repository. Examples below can better illustrate the situation:
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.
Module
Module is a modular package, but instead of being only one rpm file as a non-modular package would be, it represents a collection of one or multiple rpm packages and metadata files which are the artifact of the module build process. The metadata of a module can define multiple rpm files and modules, which are bundled and installed on the host system.
Stream
A “stream”, in the context of the Modularity project, usually represents one major version of a software, but is not exclusive to. With a stream you can then distinguish between multiple versions of software for a Fedora release. Modules can also have a default stream which is chosen if no specific stream is defined by the user, when installing the software.
Compatibility
As we already established earlier, Modules are only bundles of rpm packages which are installed together. This means that existing rpm packages can be bundled into a module. The workflow of installing modules is mostly the same as it is with non-modular packages. This is described in detail in the section Using modules.