Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-22123

On RHEL8 mariadb-server is not provided

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.3(EOL)
    • 10.3.23, 10.4.13
    • Packaging
    • None
    • Redhat 8

    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.

      Attachments

        Activity

          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.

          plmnikulin plmnikulin (Inactive) added a comment - 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.

          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.

          serg Sergei Golubchik added a comment - 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.

          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.

          plmnikulin plmnikulin (Inactive) added a comment - 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.

          People

            serg Sergei Golubchik
            rodehoed Gerwin
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.