Page Comparison

...

Assuming at least some of packages we need to ship with SIMP already belong to repo modules, how can/should we handle:

building ISO (pkglist.txt + packages.yaml

...

, etc.,)

During the process of building a SIMP ISO, we use two files

📄 DVD/<os.release.major>-pkglist.txt — a list of packages to keep from OS’s base installation media (ex:, CentOS-8.3.2011-x86_64-dvd1.iso). Anything not listed in this file will be pruned from the base OS installation packages before

📄 yum_data/packages.yaml — a manifest of additional packages needed to support a self-contained SIMP ISO installation. These are extra packages not found on the base OS’s installation media (or are not the correction version).

An example entry from the CentOS 7 packages.yaml file:

jq:
  :rpm_name: jq-1.6-2.el7.x86_64.rpm
  :source: http://mirrors.lug.mtu.edu/epel/7/x86_64/Packages/j/jq-1.6-2.el7.x86_64.rpm

Filtering an OS ISO down to its pkglist + adding external packages in packages.yaml

We can use tools like dir2module and repo2module to re-package specific modular packages into slimmer versions of their own modules and then use mergerepo_c to collect them into a slimmed-down AppStream/ repo (based on pkglist.txt) or SIMP/ (based on packages.yml). However, there are several issues that make this complicated:

• 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 requires a complete NVSCA string generating module metadata for a directory of

...

• RPMs.

• 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.

  • The master in the GitHub repo at

• At a minimum, a repackaged (slim) module’s name and stream must match its source repo’s 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 and less than the version of later modules in the full source repository.

• 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 in NVSC format, however this data is 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">`)

...

Testing ISO RPMs' completeness with a repoclosure

...

dnf repoclosure 
  --disablerepo=\* \
  --repofrompath=base,/mnt/BaseOS \
  --repofrompath =test1,/opt/dnf_reposync_from_iso \
  --arch x86_64 \
  --check test1base \
  --check basetes1

Notes:

• Make sure there is a --repofrompath= for each local repository directory that should be considered during resolution.

• Using --disablerepo=\* --repofrompath=, the repoclosure doesn’t require purpose-built *.repo files and doesn’t have to run inside a chroot/container/mock.

• The --arch x86_64Using these arguments, the repoclosure does not require purpose-built *.repo files and does not need to run within mock or a chroot64 may be needed to keep the closure focused on the ISO’s target arch.

  • As released, the EL 8.3 ISO’s AppStream/ repo doesn’t close without it.
    

Impacts to unpack_dvd &

...

self-hosted DNF repositories (for kickstarts, etc)

How should unpack_dvd handle repos that do/may contain modules?

...

that do/may contain modules?

then a site’s unpack_dvd tool should only need the files on the ISO.

This has been tested by mounting an ISO as a loopback device and

...

syncing everything (including module metadata) with dnf reposync --download-metadata […] .

How does SELinux support this?

Where do the policies for the packages in various module streams come from?

Notes:

...

So far, the selinux-*policy RPMs have handled whatever I’ve tried

...

Supporting questions

• 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 sort -u#### ### WARNING: EL and EPEL module headers are aurrent(currently) in NSVCN:S:V:C format by convention, ####but in ##### CONVENTION; in reality the ModularityLabelthis string is arbitrary and cannot be relied upon ######### to uponreflect the foractual correctsource NSVC data!module's metadata. MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4

...