modulemd 1.3.0

I almost forgot! Last week I released modulemd-1.3.0, the module metadata format specification and its reference Python implementation.

This release defines just three new fields but all of them are pretty important.

  • context, which carries a short hash generated from the module’s name, stream, version and its runtime dependencies. This is a prerequisite for a concept we call “Module Stream Expansion” and serves to uniquely identify a particular module build with its expanded dependencies, differentiating it from any other possible builds with the same name, stream and version. This might sound confusing but the basic idea is we would like to, in a future version, allow module maintainers to specify dependencies like “any platform” or “any platform but f27 with any python 3 on top”. The Module Build Service would then build all variants, each with the same name, stream and version but unique expanded dependencies and an unique context flag. System management utilities would then select the variant that is installable on the particular system, based on modules already deployed, default configuration or any additional information provided for the transaction. See the linked thread for details. context is included in the module’s identifier string, too. Did I mention we finally have a solid naming scheme proposal?
  • arch, which defines the specific hardware architecture the main components (as opposed to those pulled in via the multilib mechanism) of this module artifact are compatible with. This differs from the current common concept of basearch in the sense that this is not the architecture family but rather its specific variant. Not i386 but i586 or i686. Not armhfp but armv7hl. Meant to assist system deployment tools, just like context, arch is also part of the module’s identifier string.
  • eol, which a simple ISO 8601 date denoting the day the module reaches its End of Life. In Fedora we expect to define these in PDC for each module stream with the build system filling it in. Policies regarding module life cycles and service levels have yet to be defined but we already have a field for that. Yay.

All of these are technically optional and none of them should be manually filled in by the packager. modulemd leaves certain details undefined as they’re not all that important for the format — such as how exactly we construct the context hash, what hashing algorithm should be used, or whether this should be the same hash we use for package NVR uniqueness guarantee in koji. The only thing that matters is it’s unique among other modules with the same NSV.

Let’s see how this works out.

Petr Šabata
Just another hacker. I fancy freedom, free software, transparency, cleanliness, simplicity, natural and computer languages, and Oxford commas.