Upgrade Paths in Modularity

On the package level, upgrades of a modular system work the same way as on a traditional system — using NEVRA comparison to determine which packages are the newest. There is, however, one additional step right before the NEVRA comparison that needs to happen on a modular system — limiting which packages are going to be part of the comparison based on what modules are enabled — and that is the key difference.

There are up to three classes of RPM packages available to a modular system:

  1. Standalone packages (also refered-to as "bare RPMs" or "ursine RPMs") — packages not being part of a module. In Fedora, these are coming from the Everything repository.

  2. Modular packages — packages being part of a module. In Fedora, these are coming from the Modular repository.

  3. Hotfixes — standalone packages created on-demand by users or vendors meant to fix a critical issue before an official upgrade comes from the distribution. These need to be provided in a separate repository with a hotfix flag set. Fedora doesn’t provide such packages.

To determine the limited set of packages for the NEVRA comparison, the following algorithm is used:

  1. Take all standalone packages.

  2. Add modular packages that are part of an enabled module, and potentially replace any standalone packages having a same name. To do this, look at the target modulemd rather than the current one. This step ensures that modular packages have always a higher priority than standalone packages. In other words, standalone packages can never upgrade modular packages.

  3. Add all hotfix packages. These are just added, not replacing anything. That means hotfixes can potentially upgrade both traditional and modular packages.

The next step is to take this set of packages, and run a NEVRA comparison to determine the highest version of each package. The highest versions are then installed as a part of the upgrade process.