View Issue Details

IDProjectCategoryView StatusLast Update
0016808CentOS-8[All Projects] generalpublic2020-05-28 05:07
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?
Tagsdnf yum




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


2020-04-13 16:08

reporter   ~0036683

Any idea if anything is going to happen here?


2020-04-21 12:05

reporter   ~0036742

I would raise severity of the issue. RedHat Enterprise Linux does not have such orphan packages in the appstream repository.

The problem is that it is impossible to completely eliminate packages from some module by disabling that module. As a result remaining garbage packages could break dependency resolution during attempts to install similar application from other repositories due to higher epoch. It casts a shadow on the idea of dnf modularity. Experiments with the new feature give strange results. It would be harder to convince maintainers of 3rd party repositories to covert them to modular ones.

I have not found more specific category or tag to draw more attention to this bug. I have not noticed "AppStream", "modularity", "repository" categories. Only "dnf" is more or less relevant but the issue is not with dnf itself, it is with the extra files in the repository.

With enabled mariadb module

dnf list --available --showduplicates mariadb-server
mariadb-server.x86_64 3:10.3.17-1.module_el8.1.0+257+48736ea6 AppStream

With disabled mariadb module

dnf module disable mariadb
dnf list --available --showduplicates mariadb-server
Available Packages
mariadb-server.x86_64 3:10.3.17-1.module_el8.1.0+217+4d875839 AppStream

Some older package is available and it has "module" in its version. It should not be here. This version is not mentioned in repodata module.yaml file. Older versions might have security vulnerabilities.

Please, fix AppStream repository. Either completely remove rpm packages with modular tags that do not belong to any module or add such rpm packages to some module.yaml file.


2020-05-28 05:07

reporter   ~0037003

Checking in here, any updates

Issue History

Date Modified Username Field Change
2019-12-08 23:02 jpuhlman New Issue
2020-02-13 14:44 pclifford Note Added: 0036284
2020-04-13 16:08 jpuhlman Note Added: 0036683
2020-04-21 12:05 plmnikulin Note Added: 0036742
2020-04-21 12:06 plmnikulin Tag Attached: dnf yum
2020-05-28 05:07 jpuhlman Note Added: 0037003