Glossary
Modularity introduces a lot of new keywords to the established packaging ecosystem. This is a short glossary to get you started on the basic terms.
Modularity Project
-
Modularity project is an extension to the RPM ecosystem that allows to distribute and consume Modular Repositories with alternative content.
Modular Repository
-
Modular repository is an RPM repository extended with Module Metadata. It allows users to query and fetch information about the available Module Streams as well as RPM packages from them.
Module Stream
-
Module Stream is a collection of RPM packages as defined by the Module Metadata.
-
Usually, a Module Stream represents a certain major version or a specific build configuration of RPM packages grouped together by purpose. More specific example would be postgres:12: a Module Stream of the postgres Module with PostgreSQL version 12 and PostgreSQL-12-related packages.
Module
-
Collection of Module Streams with the same name.
-
For example: postgresql module consists of postgresql:10 and postgresql:12 Module Streams. “Module” is also frequently used as an informal reference to Module Artifact. For example: Hey buddy, I’ve just built the postgresql:12:20200101:aabbccdd:x86_64 module, go check it out!
Default Module Stream
-
Default Module Stream is a Module Stream pre-selected by the software distributor (such as Fedora or RHEL authorities) to be implicitly considered for package installation and dependency resolution and automatically enabled when packages from the stream are needed. One Module can only have zero or one Default Module Stream.
-
Example: The nodejs:14 Module Stream is the Default Module Stream of the nodejs Module and the stream contains a libuv package. When the user installs libuv (directly or indirectly), the nodejs:14 Module Stream is automatically enabled without an explicit user action. Installation of the libuv package from any other Module Stream or from a non-module repository requires explicit action (such as disabling the nodejs:14 stream).
Module Artifact
-
Module Metadata + built RPMs identified by N:S:V:C:A.
Module Build
-
Module Build is a collection of Module Artifacts with the same NSVC
Module Metadata (modulemd)
-
Module Metadata is a modulemd yaml document that contains information about a Module Artifact. Module Metadata can be found in modules.yaml in the repodata.
-
For more information see this topic.
-
The standard for yaml modulemd files is defined here.
NSVCA
-
This abbreviation describes the new naming conventions for modules i. e. Name:Stream:Version:Context:Architecture.
-
For more information see this section.
Want to help? Learn how to contribute to Fedora Docs ›