Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
I experience a bug that should have already been fixed (bug #1564159).
My system:
dnf-4.2.21-1.el8.noarch
libdnf-0.47.0-1.el8.x86_64
libsolv-0.7.11-1.el8.x86_64
libmodulemd-2.8.2-1.el8.x86_64
Neither mariadb:10.3 nor mariadb-devel:10.3 streams are active:
# dnf module list mariadb\*
Last metadata expiration check: 0:37:01 ago on Wed 20 May 2020 07:37:28 AM CEST.
AppStream from Pulp
Name Stream Profiles Summary
mariadb 10.3 client, galera, server MariaDB Module
CRB from Pulp
Name Stream Profiles Summary
mariadb-devel 10.3 MariaDB Module
Red Hat Enterprise Linux 8.3.0 AppStream - x86_64
Name Stream Profiles Summary
mariadb 10.3 client, galera, server MariaDB Module
Check that mariadb-devel:10.3 requires mariadb:10.3:
# dnf module info mariadb-devel:10.3
Last metadata expiration check: 0:39:09 ago on Wed 20 May 2020 07:37:28 AM CEST.
Name : mariadb-devel
Stream : 10.3
Version : 8010020190902091509
Context : cdc1202b
Architecture : x86_64
Profiles :
Default profiles :
Repo : pulp-crb
Summary : MariaDB Module
Description : MariaDB is a community developed branch of MySQL. MariaDB is a multi-user, multi-threaded SQL database server. It is a client/server implementation consisting of a server daemon (mysqld) and many different client programs and libraries. The base package contains the standard MariaDB/MySQL client programs and generic MySQL files.
Requires : mariadb-devel:[10.3]
: platform:[el8]
Artifacts : Judy-0:1.0.5-18.module+el8+2765+cfa4f87b.i686
: Judy-debuginfo-0:1.0.5-18.module+el8+2765+cfa4f87b.i686
: Judy-debugsource-0:1.0.5-18.module+el8+2765+cfa4f87b.i686
: Judy-devel-0:1.0.5-18.module+el8+2765+cfa4f87b.i686
: Judy-devel-0:1.0.5-18.module+el8+2765+cfa4f87b.x86_64
[...]
Enable mariadb-devel:10.3:
# dnf module enable mariadb-devel:10.3
Last metadata expiration check: 0:40:08 ago on Wed 20 May 2020 07:37:28 AM CEST.
Dependencies resolved.
===========================================================================================================================================
Package Architecture Version Repository Size
===========================================================================================================================================
Enabling module streams:
mariadb-devel 10.3
Transaction Summary
===========================================================================================================================================
Is this ok [y/N]: y
Complete!
As you can see the dependent mariadb:10.3 module was not enabled. That's the problem.
The following text only demonstrates an impact on installing some packages and is not important for resolving the cause of this bug.
As a result installing Judy-devel package from mariadb-devel:10.3 module fails, because it run-requires Judy from mariadb:10.3 module that is not active:
# dnf install Judy-devel
Last metadata expiration check: 0:42:52 ago on Wed 20 May 2020 07:37:28 AM CEST.
Error:
Problem: package Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.i686 requires Judy = 1.0.5-18.module+el8+2765+cfa4f87b, but none of the providers can be installed
- conflicting requests
- Judy-1.0.5-18.module+el8+2765+cfa4f87b.i686 has inferior architecture
- package Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.x86_64 requires libJudy.so.1()(64bit), but none of the providers can be installed
- package Judy-1.0.5-18.module+el8+2765+cfa4f87b.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)
Please do not get confused with the architectures. For some reasons Judy.i686 is in mariadb-devel module while Judy.x86_64 is in mariadb module. Pinning the architecture makes it clear:
# dnf install Judy-devel.x86_64
Last metadata expiration check: 0:43:55 ago on Wed 20 May 2020 07:37:28 AM CEST.
Error:
Problem: package Judy-devel-1.0.5-18.module+el8+2765+cfa4f87b.x86_64 requires libJudy.so.1()(64bit), but none of the providers can be installed
- conflicting requests
- package Judy-1.0.5-18.module+el8+2765+cfa4f87b.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)
Enabling mariadb:10.3 explicitly helps:
# dnf module enable mariadb:10.3
Last metadata expiration check: 0:45:25 ago on Wed 20 May 2020 07:37:28 AM CEST.
Dependencies resolved.
===========================================================================================================================================
Package Architecture Version Repository Size
===========================================================================================================================================
Enabling module streams:
mariadb 10.3
Transaction Summary
===========================================================================================================================================
Is this ok [y/N]: y
Complete!
[root@rhel-8-3 ~]# dnf install Judy-devel
Last metadata expiration check: 0:45:34 ago on Wed 20 May 2020 07:37:28 AM CEST.
Dependencies resolved.
===========================================================================================================================================
Package Architecture Version Repository Size
===========================================================================================================================================
Installing:
Judy-devel x86_64 1.0.5-18.module+el8+2765+cfa4f87b pulp-crb 76 k
Installing dependencies:
Judy x86_64 1.0.5-18.module+el8+2765+cfa4f87b pulp-appstream 131 k
Transaction Summary
===========================================================================================================================================
Install 2 Packages
Total download size: 206 k
Installed size: 746 k
Is this ok [y/N]: N
Operation aborted.
I can see my mistake. mariadb-devel:10.3 does _not_ require mariadb:10.3. It requires mariadb-devel:10.3. I.e. a reflexive dependency:
> # dnf module info mariadb-devel:10.3
> Last metadata expiration check: 0:39:09 ago on Wed 20 May 2020 07:37:28 AM CEST.
> Name : mariadb-devel
> Stream : 10.3
[...]
> Requires : mariadb-devel:[10.3]
> : platform:[el8]
That's a bug in the mariadb-devel:10.3:8010020190902091509:cdc1202b module build. Specifically in MBS that creates the -devel builds from MBS builds.
I will reassign it to mariadb-module until I found a contact on a MBS bug tracker.
I realized that current DNF in RHEL 8 has difficulties with changing run-time modular dependencies (i.e. adding a dependency on mariadb:10.3) and could start emitting spurious warnings about unsatisfied dependencies as in the case of php:7.2 (bug #1708589). Before fixing mariadb module build, please check for the DNF warnings.
Comment 9RHEL Program Management
2022-08-20 07:28:17 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.