Documentation
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
The current state of CentOS 8 createrepo_c + modulemd-tools (EPEL8) allow us to:
Find all modular RPM files that under a directory and print their module headers
This could identify dnf modules that would need to be re-created when shipping modular RPMs independently from their base repos:
find "$DIR_WITH_RPMS" -name \*.rpm \ -exec rpm -qp {} --qf '%{NVRA} %{ModularityLabel}\n' \; \ | grep -v '(none)' \ | tee modular_rpms.txt
The %{ModularityLabel}
macro is returned in (module)name:stream:version:context:arch
(NSVCA) format , so the result looks like this:
389-ds-base-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64 389-ds:1.4:8030020200831174107:618f7055 389-ds-base-devel-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64 389-ds:1.4:8030020200831174107:618f7055 389-ds-base-legacy-tools-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64 389-ds:1.4:8030020200831174107:618f7055 389-ds-base-libs-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64 389-ds:1.4:8030020200831174107:618f7055 389-ds-base-snmp-1.4.3.8-5.module_el8.3.0+473+53682548.x86_64 389-ds:1.4:8030020200831174107:618f7055 HdrHistogram-2.1.11-2.module_el8.2.0+460+6583c1d0.noarch jmc:rhel8:8020020200731165725:21dc74c6 HdrHistogram-javadoc-2.1.11-2.module_el8.2.0+460+6583c1d0.noarch jmc:rhel8:8020020200731165725:21dc74c6 Judy-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 mariadb:10.3:8010020191115015915:cdc1202b ant-1.10.5-1.module_el8.0.0+47+197dca37.noarch ant:1.10:8000020190624202340:f7e686af ant-lib-1.10.5-1.module_el8.0.0+47+197dca37.noarch ant:1.10:8000020190624202340:f7e686af aopalliance-1.0-17.module_el8.0.0+39+6a9b6e22.noarch maven:3.5:8000020190624140656:f7e686af aopalliance-1.0-20.module_el8.3.0+568+0c23fd64.noarch maven:3.6:8030020201104064112:a623df05
It may be possible to re-create specific module/streams based on the RPM’s unique headers. However, there will need to be a second data source, because the RPM ModularityLabel
has significant limitations:
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.
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/
Identify all unique modules/streams from a collection of RPM files
find "$DIR_WITH_RPMS" -name \*.rpm \ -exec rpm -qp {} --qf '%{ModularityLabel}\n' \; \ | grep -v '^(none)' | sort | uniq -c \ | sort -nk1,1 \ | tee unique_rpm_module_streams.txt
Mirror the contents of a DNF repository, preserving all modules and package groups.
(Works from CentOS 8.3 and CentOS 7.8, requires packages dnf
and dnf-plugin-core
)
An example of this mirroring a mounted CentOS 8.3 ISO’s AppStream repository:
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 should probably be the only kind of mirroring that on-site scripts like unpack_dvd use
DNF repoclosure
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, using default or enabled streams & profiles.
dnf repoclosure --repofrompath iso,"$PWD" --repo appstream --repo baseos