[archived] Building Modules¶

Historically, all packages in Fedora have followed the same branching structure in dist-git: each package had a separate branch for every numbered Fedora release, and if you wanted to update a package across all supported releases, you needed to submit the same change for each release branch.

The module definition mechanism introduced in Fedora 27 allows this to be separated such that:

• package definitions in the RPMs section of dist-git can use branches that reflect upstream API and ABI compatibility assurances (for example, using Python’s X.Y release numbers for python3 package branches)
• module definitions in the modules section of dist-git can use branches that reflect a chosen stability period, whether that’s tracking a particular upstream release series, a set of arbitrary calendar dates, a particular Fedora release, or even just the main line of upstream development.
• the system profile for a given release then nominates the default streams for each module known to the system. For example, the system profile for the F27 modular server release can be found in the f27 branch of the fedora-modular-server repo in dist-git.

On the Fedora usage side, the advantage to end users of the module system, is that while the system profile specifies a default stream, it typically doesn’t keep end users from changing that stream (modules with streams that specifically track particular Fedora releases may be an exception).

For example, Fedora 27 will select 8 as the default stream for the Node.js module. If you run dnf install nodejs in F27 Modular Server, it will implicitly give you a nodejs-8 RPM. However, unlike a traditional Fedora release, you’re also able to explicitly opt-in to downgrading to the Node.js 6 LTS release by running the command dnf install nodejs:6.

Module Development Guidelines