View Issue Details

IDProjectCategoryView StatusLast Update
0016808CentOS-8[All Projects] generalpublic2020-02-13 14:44
Reporterjpuhlman 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version8.0.1905 
Target VersionFixed in Version 
Summary0016808: modules.yaml only contains the latest version of the modulemd build
Descriptionrhel 8 modules.yaml file contains, for example, multiple definitions of the virt modulemd document, however, the same versions are only defined in separate versions of the centos8 modules.yaml file.

Is there a specific reason for this deviation?
TagsNo tags attached.

Activities

pclifford

pclifford

2020-02-13 14:44

reporter   ~0036284

I've been investigating how modules work under the hood and encountered the same thing. As far as I can tell dnf works out which packages belong to modules based on the contents of the modules.yaml file, so when updated CentOS RPMs are published and the earlier versions drop out of modules.yaml they also effectively drop out of their module. For example:

$ sudo dnf -y module disable go-toolset
... snip ...
Disabling modules:
 go-toolset
... snip ...
$ sudo dnf list go-toolset
Last metadata expiration check: 0:00:44 ago on Thu 13 Feb 2020 14:07:05 UTC.
Available Packages
go-toolset.x86_64 1.12.8-1.module_el8.1.0+232+26780282 AppStream

After disabling the "go-toolset" module there should be no "go-toolset" packages visible -- this is what happens when these commands are run on a RHEL 8 machine. Instead, as shown above, disabling "go-toolset" only hides the packages that make up the latest version, allowing the earlier versions to appear as if they were ordinary members of the AppStream repository.

The dnf code has some protection against this scenario and if you attempt to install this package it'll eventually die during the transaction check, when it looks at the RPM headers and realises go-toolset is part of a module that it doesn't know about:

$ sudo dnf install go-toolset
Dependencies resolved.
================================================================================
 Package Arch Version Repo Size
================================================================================
Installing:
 go-toolset x86_64 1.12.8-1.module_el8.1.0+232+26780282 AppStream 11 k
Installing dependencies:
 golang x86_64 1.12.8-2.module_el8.1.0+232+26780282 AppStream 643 k
 golang-bin x86_64 1.12.8-2.module_el8.1.0+232+26780282 AppStream 126 M
 golang-src noarch 1.12.8-2.module_el8.1.0+232+26780282 AppStream 6.8 M
 keyutils-libs-devel
                    x86_64 1.5.10-6.el8 BaseOS 48 k
 krb5-devel x86_64 1.17-9.el8 BaseOS 548 k
 libcom_err-devel x86_64 1.44.6-3.el8 BaseOS 38 k
 libkadm5 x86_64 1.17-9.el8 BaseOS 184 k
 libselinux-devel x86_64 2.9-2.1.el8 BaseOS 199 k
 libsepol-devel x86_64 2.9-1.el8 BaseOS 86 k
 libverto-devel x86_64 0.3.0-5.el8 BaseOS 18 k
 openssl-devel x86_64 1:1.1.1c-2.el8 BaseOS 2.3 M
 pcre2-devel x86_64 10.32-1.el8 BaseOS 605 k
 pcre2-utf16 x86_64 10.32-1.el8 BaseOS 228 k
 pcre2-utf32 x86_64 10.32-1.el8 BaseOS 220 k
... snip ...
Running transaction check
No available modular metadata for modular package 'go-toolset-1.12.8-1.module_el8.1.0+232+26780282.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'golang-1.12.8-2.module_el8.1.0+232+26780282.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'golang-bin-1.12.8-2.module_el8.1.0+232+26780282.x86_64', it cannot be installed on the system
No available modular metadata for modular package 'golang-src-1.12.8-2.module_el8.1.0+232+26780282.noarch', it cannot be installed on the system
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: No available modular metadata for modular package

Issue History

Date Modified Username Field Change
2019-12-08 23:02 jpuhlman New Issue
2020-02-13 14:44 pclifford Note Added: 0036284