[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: |
|
||||
| Description |
|
Hi, It seems that on EL8 the MariaDB rpm is not providing mariadb-server (mind the case) as it does on EL7:
Checking the RPMbuild code: 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. Fixing of the problems should improve user experience and reduce amount of questions related to installation problems. A bit more details 1. ProvidesWhen "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. ConflictsLack 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)
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 repositoryIt could be better solution than marking repository as hotfix ( The idea of dnf.modularity(7) is to allow choice of version of some application, e.g.
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
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.
https://dnf.readthedocs.io/en/latest/command_ref.html#module-command 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.
should fail early with DepsolveError, not during transaction check. I hope, solver could find a better option if it has proper metadata. |