Versions Compared

Key

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

Documentation

...

https://docs.fedoraproject.org/en-US/modularity/

...

https://dnf.readthedocs.io/en/latest/

...

https://dnf-plugins-core.readthedocs.io/en/latest/

...

https://sgallagh.wordpress.com/2019/08/14/sausage-factory-modules-fake-it-till-you-make-it/

  • Building a module outside of Fedora

https://pagure.io/modularity/issue/141

> * AGREED: Profiles cannot be removed during the lifetime of the stream in order to avoid breaking scripts. Options may exist for exceptional cases on an individual basis. (contyk, 15:41:06)

Goals

  • Can the ISO build still reduce packages

Modularity CLI examples

...

Goals

Assuming at least some of the packages involved belong to repo modules, determine how to handle:

pkglist + packages.yaml => tarball ISO

Can the pkg/tar/ISO build process still create a usable ISO as it currently does, by:

  • filtering an OS ISO down to its pkglist

  • adding external packages in packages.yaml

  • running repoclosure

If it can be done: How?

If not: What alternatives are there?

unpack_dvd & kickstart repositories

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

SELinux

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

Modularity CLI examples

Simple dnf module commands

View all modules

Code Block
dnf module list --all

View a module’s available streams

Code Block
breakoutModewide
# 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

View packages in a module

Code Block
dnf module repoquery nodejs
Info

It looks dnf module repoquery only reports on the default stream, regardless of the module-spec specified (tested on EL8.3)

View modules/profiles that provide a package

Code Block
dnf module provides nodejs
Info

This is one of the few module commands that lists the Repo that provides the module

View the packages in each profile (for a specific stream)

Code Block
languages
]# dnf module info --profile  nodejs:12
Last metadata expiration check: 2:59:10 ago on Thu 11 Mar 2021 11:02:32 PM UTC.
Name        : nodejs:12:8030020210304194546:30b713e6:x86_64
common      : nodejs
            : npm
development : nodejs
            : nodejs-devel
            : npm
minimal     : nodejs
s2i         : nodejs
            : nodejs-nodemon
            : npm

Find all modular RPM files that under a directory and print their module headers

...

Note

By convention, RPMs' ModularityLabel string is in NVSC format, which doesn’t include profile information. Any module streams constructed solely on the RPM header would lose all the original streams' profiles.

Note that the repo2module tool just creates a default profile called everything.

Note

We can’t rely on RPMs' ModularityLabel string to be in NVSC format, either!

“The ModularityLabel can be any string at all. In Fedora, we have a convention to use name:stream:version:context to indicate from which build the RPM originally came from, but this is not to be relied upon. It may change at any time and it also may not be accurately reflective of the module in which it currently resides, due to component-reuse in the Module Build System.”

https://sgallagh.wordpress.com/2019/08/14/sausage-factory-modules-fake-it-till-you-make-it/

...

Mirror the contents of a DNF repository, preserving all modules and package groups. 

The current state of CentOS 8 createrepo_c + modulemd-tools (EPEL8) allow us to:

(Works from CentOS 8.3 and CentOS 7.8, requires packages dnf and dnf-plugin-core )

...

Code Block
languagebash
PATH_TO_LOCAL_MIRROR=/path/to/Appstream
PATH_TO_SOURCE_REPO=/mnt/AppStream

dnf reposync \
  --download-metadata --downloadcomps \
  --download-path "$PATH_TO_LOCAL_MIRROR" \
  --repofrompath iso,"$PATH_TO_SOURCE_REPO" \
  --repoid iso

# Useful EL8-only options: --remote-time --norepopath

This dnf reposync should probably be the only kind of modular-capable mirroring that on-site scripts tools like unpack_dvd should use.

DNF repoclosure

The ISO build process (really the tar build process) runs repoclosure to make sure the packages on the ISO will be self-contained.

Code Block
dnf repoclosure --repofrompath iso,"$PWD" --repo appstream --repo baseos
Info

Judging by the bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1547041, dnf repoclosure is not module-aware.It currently resolves from module packages, , in the sense that its resolver does not consider packages in all available modules/streams.

The current behavior only resolves module packages using default or enabled streams & profiles.

Documentation

...