Versions Compared

Old Version 9

changes.mady.by.user Chris Tessmer

Saved on

compared with

New Version 10

changes.mady.by.user Chris Tessmer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel3

Questions

Assuming at least some of the packages involved belong to repo modules, how can/should we handle:

pkglist + packages.yaml => building tarball/ISO

Can the pkg/tar/ISO build process still create a usable ISO as it currently does, or will something have to change?

  • filtering an OS ISO down to its pkglist

Note

Possible (but involved)

We can probably use dir2module to re-package just the modules we need and mergerepo_c to build them into a slimmed-down AppStream based on pkglist.txt (or a SIMP/ repo for packages.yml)

Details at the end of the RPM module header examples

Warning

Currently failing:

Currently, an AppStream repo mirrored with dnf reposync fails dnf repoclosure rather badly, while the real AppStream repo only has two unresolved deps (both ursine).

If it can be done: How?

If not: What alternatives are there?

Impacts to unpack_dvd & kickstart repositories

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

Tip

Recommendation:
Assuming we can limit any module editing to the tarball/ISO build process (above), unpack_dvd should just mount the ISO as a loopback device and sync everything with dnf reposync --download-metadata … .

How does SELinux support this?

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

Notes:

Supporting questions

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

probably:

...

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

Process:

...

Table of Contents
maxLevel3

Questions

Assuming at least some of the packages involved belong to repo modules, how can/should we handle:

pkglist + packages.yaml => building tarball/ISO

Can the pkg/tar/ISO build process still create a usable ISO as it currently does, or will something have to change?

  • filtering an OS ISO down to its pkglist

e

Note

Possible (but involved)

We can probably use dir2module to re-package just the modules we need and mergerepo_c to build them into a slimmed-down AppStream based on pkglist.txt (or a SIMP/ repo for packages.yml)

Details at the end of the RPM module header examples

Warning

Currently failing:

Currently, an AppStream repo mirrored with dnf reposync fails dnf repoclosure rather badly, while the real AppStream repo only has two unresolved deps (both ursine).

If it can be done: How?

If not: What alternatives are there?

Impacts to unpack_dvd & kickstart repositories

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

Tip

Recommendation:
Assuming we can limit any module editing to the tarball/ISO build process (above), unpack_dvd should just mount the ISO as a loopback device and sync everything with dnf reposync --download-metadata … .

How does SELinux support this?

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

Notes:

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
          colourYellow
          titleWARNING
          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
          colourRed
          titleDO 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: EL and EPEL module headers are aurrent in NSVC format by 
####         CONVENTION; in reality the ModularityLabel cannot be relied 
####         upon for correct NSVC data!
MODULE_HEADER=nodejs:10:8020020200707141642:6a468ee4

Modularity CLI examples

Simple dnf module commands

...