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
3on 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
contextflag. 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.
contextis 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
multilibmechanism) 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
armv7hl. Meant to assist system deployment tools, just like
archis 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.