Page Comparison

...

...

• RPM packages from repo modules contain a ModularityLabel header that is unique to the module’s name + stream + version + context + architecture (NSVCA). DNF must install these RPMs from modules (with modular metadata)—and will refuse to install them as ursine packages.

  • dir2module and repo2modules require a complete NSVCA string generating module metadata for a directory of RPMs.

  • 5️⃣ The dir2module script provided by the EPEL8 RPM modulemd-tools-0.7-1.el8.noarch does not create a default (or any) profile for the module it creates; it is effectively useless; use repo2module instead (which is still missing the Arch in NSVCA).

• A repackaged (slim) module’s name and stream and context and architecture must match the values in the source repo’s metadata for the original module.

  • This is required so the packages maintain continuity with the complete upstream repo (e.g., receiving update from the complete AppStream repo, epel-modular, etc)

  • The versionnumber must evaluate to more than the earlier (module versions) and less than the version of later modules in the full source repository. This number (like stream and context) is an arbitrary string set by the build platform, so we have to get it

  • For practical purposes, you need to mirror the repo’s metadata YAML at the same time as you retrieve the packages—it might be updated later, even if the packages you see hosted there are the same

• The ModularityLabel header is string unique to a module builds' NSVCfor a particular platform. The header data in RPMs packaged by RHEL/CentOS build system looks useful because a string it’s in NSVC format, however this data is actually arbitrary and cannot be relied uponto provide accurate NSVC data for the module.

• The only canonical source for a module’s correct NSVCA/P data is the source repo’s metadata (generally under repodata/{XXXXX}-modules.yaml.gz, and defined by repodata/repomd.xml under <data type="modules">`)

• 🎉 I’ve tested a repacked “slim” repo alongside a repo with the full module w/identical NSVCA details, and it successfully resolved its metadata/packages with the full module.

  • This should also behave correctly with updated modules, but I haven’t been able to stage that yet.

...

...

Simple dnf module commands

View all modules and streams

dnf module list --all

...

# dnf module list --available nodejs

Waiting for process with pid 79896 to finish.
Last metadata expiration check: 0:00:01 ago on Fri 12 Mar 2021 02:03:02 AM UTC.
CentOS Linux 8 - AppStream
Name                   Stream                 Profiles                                             Summary
nodejs                 10 [d]                 common [d], development, minimal, s2i                Javascript runtime
nodejs                 12                     common [d], development, minimal, s2i                Javascript runtime
nodejs                 14                     common [d], development, minimal, s2i                Javascript runtime

Extra Packages for Enterprise Linux Modular 8 - x86_64
Name                   Stream                 Profiles                                             Summary
nodejs                 13                     default, development, minimal                        Javascript runtime

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

With nicer formatting:

# 

View all default streams

The 21 and 11 are the first two field widths. These may vary depending on the length of the stream names.

dnf module list \
  | awk -v FIELDWIDTHS="21 11" '{printf "%-20s %s\n", $1, $2}' \
  | grep '\[d\]'

A stab at at more automation-friendly formatting

dnf module list \
  | egrep -v '^(Extra|Name|Hint:|CentOS|Last)' \
  | sed -e '/^$/d' \
  | awk '{printf "%-20s %s\n", $1, $2}' \
  | sort
  
389-directory-server next
389-directory-server stable
389-directory-server testing
389-ds               1.4 
ant                  1.10
avocado              82lts
avocado              latest
cobbler              3
container-tools      1.0
container-tools      2.0
container-tools      rhel8
dwm                  latest
freeradius           3.0
gimp                 2.8
go-toolset           rhel8
httpd                2.4
idm                  DL1
idm                  client
inkscape             0.92.3
javapackages-runtime 201801
jmc                  rhel8
libselinux-python    2.8
libuv                epel8-buildroot
llvm-toolset         rhel8
  

...

• Create a modular repo from packages that already have a common module header
  

  Status
  colour Yellow title WARNING

  The approach of taking N:S:V:C:A from the RPM headers below is a.) incomplete and b.) cannot be relied upon to be accurate or present—the ModularityLabel header can contain any String.

  

  Status
  colour Red title DO NOT PRODUCTIZE

  Use another means to obtain N:V:S:C:A data; preferably from the repo itself (the data is sourced from the source repository’s {XXXXX}-modules.yaml.gz file)
  

  Code Block

  # Get the ModularityLabel from the RPMs ########################################################## #### UPDATE: DO NOT USE OR PRODUCTIZE THIS TECHNIQUE ##### ########################################################## # Notes: # - All RPMs in the module must have a SINGLE and IDENTICAL ModularityLabel # - The only thing required of this String is that it is unique to RPMs # from other modules (and different versions/contexts of this module) find "$DIR_WITH_RPMS" -name \*.rpm \ -exec rpm -qp {} --qf '%{ModularityLabel}\n' \; \ | sort -u ### WARNING: the ModularityLabel headers in RPMs build by EL and EPEL #### are (currently) in N:S:V:C format by convention, but in ##### reality this string is arbitrary and cannot be relied upon ##### to reflect the actual source module's metadata. ##### The actual NVSCA/P data can *ONLY* be obtained from the ##### original repo's metadata MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4

...

Since RedHat took over, it has become very difficult to find up-to-date documentation or discussions, even (especially?) in BZ.

• Fedora Council and the future of Modularity (March 2020 blog post)

  > “ Since then, responsibility for Modularity development in Red Hat moved to a new team. This presents a good opportunity to reset opinions and start anew. As the new team gets their arms around Modularity, you can expect an updated Objective proposal that will improve Modularity for Fedora. “

  Why Modularity? An explanation and list of links.

• RHEL 9 and modularity (18 June 2020, Fedora devel@ mailing list)

  • Discussion with official RedHat rep, after taking modularity from Fedora and moving its development to an internal DNF team.

  • There’s also a side-discussion in the middle about the “inevitability” of moving the modular “namespacing” (N:S?) into RPM’s headers/tags (like ModularityLabel), where several of Fedora’s former modular WG members chime in with some educational

    • Bonus: Stephen Gallagher on containers vs flatpak

Projects

More esoteric things that may come in handy in the future:

...