Zen

Source string Source string

57/10000 · 57

The string is read only.

English Actions
Simply put, **modulemd is a file that defines which packages get built for which releases**. It includes a summary and a description, a list of source RPM packages, build information i.e. build order and macros, and usage information i.e. installation profiles and licenses.
A typical modulemd example
A typical modulemd file looks similar to the following examples. Read on for more details about each part of the modulemd file.
Feel free to copy/paste this example when creating your new module.
document: modulemd-packager
version: 3
data:
# === Information about this module ==================================
# (Can be copied from the main RPM package, but doesn't need to be)
summary: An example module
description: >-
A module for the demonstration of the metadata format. Also,
it can span multiple lines.
# === License of this modulemd file ==================================
license:
- MIT
# === Module context configurations ===========================================
# (For which Fedora releases to build?)
configurations:
# context:
# A string of up to ten [a-zA-Z0-9] characters representing a
# a build and runtime configuration for this stream. This string is
# arbitrary but must be unique in this module stream.
# Type: MANDATORY
- context: CTX1
# platform:
# Defines the distribution and release to build on and run against.
# Type: MANDATORY
platform: f32
# buildrequires:
# A dictionary of the build-time dependencies on other module streams.
# Each configuration may depend on a single stream of a dependency.
# The dictionary key is the name of the module and the dictionary value
# is a single-element list containing the name of the stream.
#
# Type: Optional
buildrequires:
appframework: [v1]
# requires:
# A dictionary of the run-time dependencies on other module streams.
# Each configuration may depend on a single stream of a dependency.
# The dictionary key is the name of the module and the dictionary value
# is a single-element list containing the name of the stream.
#
# Type: Optional
requires:
appframework: [v1]
# buildopts:
# Component build options
# Additional per component type module-wide build options.
#
# IMPORTANT: Due to limitations in the modulemd-stream v2 format, the
# buildopts from the first configuration in the list will apply to
# ALL configurations when building for modulemd-stream v2. They will
# apply separately when building for module-stream v3.
#
# Type: OPTIONAL
buildopts:
# rpms:
# RPM-specific build options
#
# Type: OPTIONAL
rpms:
# macros:
# Additional macros that should be defined in the
# RPM buildroot, appended to the default set. Care should be
# taken so that the newlines are preserved. Literal style
# block is recommended, with or without the trailing newline.
#
# Type: OPTIONAL
macros: |
%demomacro 1
%demomacro2 %{demomacro}23
# whitelist:
# Explicit list of package build names this module will produce.
# By default the build system only allows components listed under
# data.components.rpms to be built as part of this module.
# In case the expected RPM build names do not match the component
# names, the list can be defined here.
# This list overrides rather then just extends the default.
# List of package build names without versions.
#
# Type: OPTIONAL
whitelist:
- fooscl-1-bar
- fooscl-1-baz
- xxx
- xyz
# arches:
# Instructs the build system to only build the
# module on this specific set of architectures.
# Includes specific hardware architectures, not families.
# See the data.arch field in the modulemd-stream spec for details.
# Defaults to all available arches.
#
# Type: OPTIONAL
arches: [i686, x86_64]
# Alternate example with no dependencies
- context: CTX2
platform: f33
# === Module API (optional, but encouraged) ==========================
# (Which packages are API-stable?)
api:
rpms:
- package-one # <- Binary RPM package name
- package-one-extras # <- Binary RPM package name
- package-one-cli # <- Binary RPM package name
- package-one-devel # <- Binary RPM package name
- package-two # <- Binary RPM package name
# === Package filtering ==============================================
# (Which packages should not be included into the resulting module)
filter:
rpms:
- subpackage-one # <- Binary RPM package name
# === Installation profiles (optional, but encouraged) ===============
# (Helping users with installation by providing predefined groups)
profiles:
default: # <- Name of the profile
description: A standard installation.
rpms:
- package-one # <- Binary RPM package name
- package-one-extras # <- Binary RPM package name
- package-two # <- Binary RPM package name
cli: # <- Name of the profile
description: A command-line client.
rpms:
- package-one-cli # <- Binary RPM package name
# === Packages in this module ========================================
# (Referenced by their dist-git repo name + branch name)
components:
rpms:
first-package: # <- Source RPM package name
ref: 3.0 # <- Branch name in dist-git
rationale: Provides the core functionality.
second-package: # <- Source RPM package name
ref: latest # <- Branch name in dist-git
rationale: Web UI for the first-package.
Common modulemd definitions
These are the common parts of a modulemd file, used in the example above. Advanced definitions, including a complex example of Module Stream Expansion (MSE), are towards the end of this page.
Document header
Every modulemd starts with these three lines:
document: modulemd-packager
version: 3
data:
... <1>
All the following definitions go here, under _data_.
Information about this module
Tell users what this module represents by writing a summary and a description.
summary: An example module
description: >- <1>
A module for the demonstration of the metadata format. Also,
it can span multiple lines.
The `>-` means new line in YAML. Useful for longer blocks of text, such as the description!
License of this modulemd file
This is a license of this very modulemd file and it doesn't need to be modified. The build system adds licenses of all packages to this list automatically.
license:
- MIT <1>
A license for this modulemd file. Fedora content, such as SPEC files or patches not included upstream, uses the MIT license by default, unless the component packager declares otherwise.
[[context]]Module context configurations
Each context configuration describes how a module stream and its components should be build and run. A single-context example:
configurations:
- context: CTX1 <1>
platform: f32 <2>
buildrequires:
appframework: [v1] <3>
requires:
appframework: [v1] <4>
A context name for the single configuration.
An identifier of a major release of a distribution this context will be built and it will run on.
Module streams to enable when building this context (build-time modular dependencies).

Loading…

User avatar None

String updated in the repository
document: modulemd-packager
version: 3
data:
... <1>
document: modulemd-packager
version: 3
data:
... <1>
2 years ago
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

9903114 String information

Source string description
type: delimited block -
Flags
no-wrap, read-only
Source string location
./pages/building-modules/fedora/defining-modules.adoc:168
String age
2 years ago
Last updated
a year ago
Source string age
2 years ago
Translation file
pot/master/pages/building-modules/fedora/defining-modules.pot, string 17