[MDEV-22123] On RHEL8 mariadb-server is not provided Created: 2020-04-02  Updated: 2022-05-21  Resolved: 2020-05-06

Status: Closed
Project: MariaDB Server
Component/s: Packaging
Affects Version/s: 10.3
Fix Version/s: 10.3.23, 10.4.13

Type: Bug Priority: Critical
Reporter: Gerwin Assignee: Sergei Golubchik
Resolution: Fixed Votes: 1
Labels: None
Environment:

Redhat 8


Issue Links:
PartOf

 Description   

Hi,

It seems that on EL8 the MariaDB rpm is not providing mariadb-server (mind the case) as it does on EL7:

 
[EL7] [root@xxxxx ~]$] rpm -q --whatprovides mariadb-server
MariaDB-server-10.3.11-1.el7.centos.x86_64
 
[EL8] [root@xxxxx ~]$] rpm -q --whatprovides mariadb-server
no package provides mariadb-server

Checking the RPMbuild code:
https://github.com/MariaDB/server/blob/mariadb-10.4.11/cmake/cpack_rpm.cmake#L210
Shows indeed that 8 is not listed.

We are running against problems with Plesk for example. But I think there might be a lot more 3rd party rpms relying on mariadb-server.

I don't know if that has todo anything with dnf module fiasco.



 Comments   
Comment by plmnikulin (Inactive) [ 2020-04-22 ]

I suppose that current MariaDB repository for CentOS 8 has a number of issues:

1. "Provides" RPM tags in packages miss related names from the AppStream repository, e.g. MariaDB-server should have mariadb-server among provides options.
2. Conflicts should be specified since it is anyway impossible to install MariaDB-server from mariadb.org and mariadb-server from AppStream CentOS repository simultaneously.
3. Consider modular repository for centos-8. AppStream repository provides mariadb packages using a module. It should be better way than module_hotfixes=1 or epoch war.

Fixing of the problems should improve user experience and reduce amount of questions related to installation problems.

A bit more details

1. Provides

When "provides" tag in RPM package contains package name from OS vendor repositories, it is easier to use packages as drop-in replacement. 3rd party packages could just require mariadb-server and do not care that MariaDB is actually installed from upstream repository instead of linux vendor packages.

2. Conflicts

Lack of proper conflicts postpones installation error to later stages. Currently DNF recognizes problems during transaction check when packages have been already downloaded. It detects that packages contain the same files, either installed earleir or downloaded during execution of the same DNF command. It is better to give DNF a chance to report problems during dependency resolution step before downloading of files or even to choose a consistent set of packages without any conflicts. For example try to install mariadb-server from AppStream when mariadb.org repository is configured (most of output is skipped)

dnf install mariadb-server
Installing:
 mariadb-server                  x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                         16 M
Installing dependencies:
 mariadb                         x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                        6.1 M
 mariadb-common                  x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                         62 k
 mariadb-connector-c             x86_64           3.0.7-1.el8                                        AppStream                        148 k
 mariadb-errmsg                  x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                        232 k
 MariaDB-client                  x86_64           10.3.22-1.el8                                      mariadb-oldstable-10.3            11 M
 MariaDB-common                  x86_64           10.3.22-1.el8                                      mariadb-oldstable-10.3            87 k
Installing weak dependencies:
 mariadb-backup                  x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                        6.0 M
 mariadb-gssapi-server           x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                         49 k
 mariadb-server-utils            x86_64           3:10.3.17-1.module_el8.1.0+257+48736ea6            AppStream                        1.6 M
...
<DepsolveError could be thrown here>
<Downloading of packages>
...
Error: Transaction check error:
  file /usr/bin/mysql conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysql_plugin conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysql_waitpid conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlaccess conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqladmin conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlbinlog conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlcheck conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqldump conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlimport conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlshow conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64
  file /usr/bin/mysqlslap conflicts between attempted installs of mariadb-3:10.3.17-1.module_el8.1.0+257+48736ea6.x86_64 and MariaDB-client-10.3.22-1.el8.x86_64

Notice dependency resolution result with mix of AppStream and mariadb.org packages. Alternatively file conflicts may happen during attempt to replace earlier installed mariadb-server with MariaDB-server. Please, pay attention to the mariadb-connector-c-config package that contains the same file as MariaDB-shared

Modular repository

It could be better solution than marking repository as hotfix (MDEV-20673).

The idea of dnf.modularity(7) is to allow choice of version of some application, e.g.

dnf module list php
CentOS Linux 8 - AppStream (psabr.qa.plesk.ru)
Name Stream     Profiles                   Summary               
php  7.2 [d][e] common [d], devel, minimal PHP scripting language
php  7.3        common, devel, minimal     PHP scripting language
 
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

During upgrades versions from other modules or from non-modular repositories are not considered.

I believe that 10.3, 10.4 (old stable, stable), etc versions in the repository at mariadb.org could be provided as streams of a module, so users could use this module instead of AppStream one.

I could not provide ready to use recipe of creation of modular repository. Essentially Modularitylabel RPM tag should be added to each RPM package as in

rpm -q --qf '%{Modularitylabel}s' mariadb-server
mariadb:10.3:8010020190814171449:cdc1202b

and module.yaml file should be added to repodata. You could inspect the files in the AppStream repository. Notice modulemd-defaults and modulemd documents inside.

A couple of warnings.

RedHat Enterprise Linux appstream repository looks good, but unfortunately CentOS AppStream repository is a bit dirty currently. Some packages are not described in module.yaml files, so they remain available even when mariadb module is disabled, so could generate dependency resolution problems. See https://bugs.centos.org/view.php?id=16808

I do not have strong opinion if the same name "mariadb" should be used for the module or another one should be chosen for the repository that is external in respect to native CentOS ones. It is uncertain for me if dnf module command correctly handles modules with same name in different repositories.

Due to the following remark the scenario of migration from e.g. MariaDB-10.3 to MariaDB-10.4 is not clear for me if versions are represented as module streams.

This command (dnf module install) cannot be used for switching module streams. It is recommended to remove
all installed content from the module and reset the module using the reset command.

https://dnf.readthedocs.io/en/latest/command_ref.html#module-command
Maybe it worth discussing such upgrade in some fedora or centos mail list.

I still believe that modular repository should have better compatibility with AppStream.

Comment by Sergei Golubchik [ 2020-05-04 ]

plmnikulin, thanks, that's a very helpful comment!

In this issue, though, I'll only fix provides. And may be conflicts, if it'll be necessary, but until now our packages worked on previous CentOS/RHEL/Fedora versions without explicit Conflict: tags.

I definitely won't do modular repository now, it'll need more time and I'd rather not delay provides/conflicts fix. If you'd like I can create a new issue for the modular repository, but I cannot say when it'll be implemented.

Comment by plmnikulin (Inactive) [ 2020-05-06 ]

Certainly proper provides have significantly higher priority than avoiding of marking repository as hotfix. Thank you for the efforts to fix this issue.

As to conflicts, I am unsure. My concern is just that commands that tries to install MariaDB related packages from both AppStream and mariadb.org repositories (directly or through dependencies), e.g.

dnf install mariadb-server

should fail early with DepsolveError, not during transaction check. I hope, solver could find a better option if it has proper metadata.

Generated at Thu Feb 08 09:12:22 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.