Content Comparison

...

...

• 1️⃣: You can’t simply [download the modular RPMs you want/remove the modular RPMS you don’t need/throw a bunch of modular RPMs together] and run createrepo to re-host them. You also need the correct metadata for all downloaded modular RPMs' streams, and special new commands.

  • AFAICT, this metadata can only be obtained from the source repo.

  • There isn’t a complete “roll-your-own” solution to create modular repositories yet. Most of the tooling is meant to mirror existing repositories. There are community tools, but they are incomplete, unsupported, and buggy.

• 2️⃣: createrepo_c is needed to create a useable modular repository.
  However, we need quite a few things before that:

  • ⚠4️⃣ We need to get the The correct modulemd data (see format specs) for modules.yaml from the original repository.

  • 5️⃣ We need some Some way of generating the modulemd YAML data for each module.

  • 6️⃣ We need to be able to The ability to add all the the modules' modulemd data into a single modules.yaml file for the entire repository.

  • ⚠7️⃣Finally we need to run the correct commands ⚠7️⃣The correct tools to create/merge the repo and the module metadata (createrepo_mod or the *_c commands it runs)

• 3️⃣: yum-utilsprovides a CLI compatibility layer with the newer DNF sub-commands (including repoclosure), but may require specific arguments (documented further below)

  • dnf repoclosureis sort of module-aware (bz#1547041), and may need extra logic to module enable non-default streams that need to be considered while depsolving.
    

...

It is not yet tested (but possible) that context and/or profile (/P) must match as well

...

• RPM packages from repo modules contain a ModularityLabel header that is unique to the module’s name + stream + version + context + architecture (NVSCA). 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 NVSCA 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 NVCSA).

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

  • 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 module’s versionnumber must evaluate to more than the versions of earlier modules 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' NVSCfor a particular platform. The header data in RPMs packaged by RHEL/CentOS build system is currently looks useful because a string it’s in NVSC format, however this data is actually arbitrary and cannot be relied uponto provide accurate NVSC data for the module.

• The only canonical source for a module’s correct NVSCA/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">`)

...

Remaining unknowns:

• 🎉 I’ve tested a repacked “slim” repo

...

• alongside a

...

• repo with the full module w/identical NVSCA 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.

Testing ISO RPMs' completeness with a repoclosure

...

...

• Can we repackage a “thinned-out” module with only select packages?

  • probably:

    • EL8 RPM prereqs: createrepo_c (appstream) + modulemd-tools (epel)

    • Process:

      1. Create initial repo with ursine modules

         Code Block
         mkdir -p $NEW_REPO_DIR/Packages/ursine cp "${URSINE_PACKAGE_FILES[@]}" "$NEW_REPO_DIR/Packages/ursine/" cd "$NEW_REPO_DIR" createrepo_c .

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

         Status
         colour Yellow title WARNING

         The approach of taking NSVCA from the RPM headers is incomplete and cannot be relied upon to be accurate or available—the ModularityLabel header can contain any String

         

         Status
         colour Red title DO NOT PRODUCTIZE

         Use another means of obtaining this 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 ### WARNING: All RPMs in the module must have a SINGLE and IDENTICAL ModularityLabel 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. MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4

...