Description of problem: Using RDO repositories with CentOS 7.3 following error is found when trying to install mariadb-server: Transaction check error: file /usr/lib64/mysql/plugin/dialog.so from install of mariadb-common-3:10.1.18-3.el7.x86_64 conflicts with file from package mariadb-libs-1:5.5.52-1.el7.x86_64 file /usr/lib64/mysql/plugin/mysql_clear_password.so from install of mariadb-common-3:10.1.18-3.el7.x86_64 conflicts with file from package mariadb-libs-1:5.5.52-1.el7.x86_64 We have similar issue when trying to install mariadb package. Version-Release number of selected component (if applicable): CentOS 7.3 with mariadb-libs-1:5.5.52-1.el7.x86_64 mariadb-server-3:10.1.18-3.el7 from RDO repos How reproducible: allways unless workaound is applied. Steps to Reproduce: 1. CentOS 7.3 machine with mariadb-libs-5.5.52-1.el7.x86_64 (i think this is usually installed in base installation as dependency for postfix which is in core yum group by default) 2. Enable RDO repos: yum install -y centos-release-openstack-newton 3. Try to install mariadb-server yum install -y mariadb-server Actual results: yum command fails with mentioned transaction check error Expected results: Package mariadb-server should be installed. (I guess) mariadb-libs should be updated unles backwards compatibility for mariadb-server to previous version of mariadb-libs is ensured. Additional info: This error has been introduced by mariadb-libs version in 7.3 which moved dialog.so and mysql_clear_password.so to mariadb-libs according to https://bugzilla.redhat.com/show_bug.cgi?id=1138843. These too files are in mariadb-common in RDO.
@apevec there's a PR here at https://github.com/rdo-common/mariadb/pull/5. who should be pulling these in and also doing the builds on CBS?
OK I'm all confused here. the issue is mariadb-server 10.1 is not requiring mariadb-libs 10.1 to get installed and we're stuck with the 5.5 version that is doing things differently. I would think mariadb-server should pull in mariadb-libs 10.1.
question for honza: in rhel, we have dialog.so and mysql_clear_password.so *only* in libs. In fedora / RDO, it seems they are in common. Can we in fedora/RDO move these to libs as well, and assume these are *only* needed for mysql client and *not* server?
Actually the plugins were moved from libs to common because they can be used by utilities and client library as well. If we had them only in -libs, then they would be missing for utilities (mysql, ...). But I see the problem you have, so we'll need to figure out something..
Copying mburn's comment from now closed rdo-common PR: "The base conflict here could be solved with a single line change in the RDO spec (and in fedora spec if it would be accepted). Make mariadb-common require mariadb-libs = <version> The issue is that the base image from centos contains mariadb-libs. OpenStack wants to install mariadb-common and gets the 10.1 version from RDO. It does not update mariadb-libs because there is no dependency between them, so the files conflict. If there was a dependency, it would pull both packages in the yum transaction and the conflict would not occur." From Honza's justification for common/libs split, adding common -> libs deps would defeat it. Current dep resolution with installed mariadb-libs 5.5. is: mariadb (10) -> mariadb-common (10) -> /etc/my.cnf[*] -> mariadb-libs (5.5) hence libs is not updated. [*] https://github.com/rdo-common/mariadb/blob/rdo-common/mariadb.spec#L304 AFAICT there needs to be an explicit dep mariadb -> mariadb-libs = %{sameevr} which then pulls mariadb-common. mariadb-common is not installed directly, it is via mariadb main package: https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp#L58-L60
(In reply to Alan Pevec from comment #5) > "The base conflict here could be solved with a single line change in the RDO > spec (and in fedora spec if it would be accepted). Just to make it clear, what is the relation between fedora and RDO build -- you take fedora sources and just rebuild for RDO or you have also some downstream changes for RDO? > From Honza's justification for common/libs split, adding common -> libs deps > would defeat it. Exactly. > AFAICT there needs to be an explicit dep mariadb -> mariadb-libs = > %{sameevr} which then pulls mariadb-common. It would effectively mean to use the newer client library for all packages that link to it -- however, it should work thanks to back-ward compatibility of the library. > mariadb-common is not installed directly, it is via mariadb main package: > https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params. > pp#L58-L60 Another idea -- we might also do some tricks (%if %rhel...) to do things differently in Fedora and RHEL, e.g. package the client plugins into a new separate sub-package and this sub-package would be Required/Recommended only in Fedora. Bad idea?
IIUC, we are in the situation where: . Fedora/RDO package has the two plugins libs in mariadb-common (for good reasons exposed in comment #4), . RHEL package still has those libs in mariadb-libs. In the RDO/Openstack use case, we install RDO mariadb packages on a CentOS image, which comes pre-installed with RHEL-like mariadb-libs 5.5.52, which is what causes the issue. I don't think we have issue "upgrading" RDO/Openstack installation, because the general upgrade path in OpenStack triggers a yum upgrade: so any mariadb-libs installed would be upgraded to RDO-provided 10.1.8 and mariadb-server 10.1.8 would install cleanly. So it looks to me that we can narrow the issue to "first install of RDO mariadb packages on a fresh Centos7.3". So to fix it we could: 1) fix the way the RDO package get installed on the first OpenStack install. -> This is done by puppet code in puppet-tripleo, which I believe ultimately calls puppet-mysql [1]. So we'd need to tell that code to install an additional package to overcome the error. 2) add a dependency in RDO specfile to require mariadb-server to depend on mariadb-libs. This way, any install of RDO mariadb will replace the stock mariadb-libs from CentOS. The latter introduces a small divergence from current Fedora's specfile, but it seems sufficient to overcome the issue and gives us time to think of best ways of reconciling Fedora and RHEL specfiles eventually. Alan (or Honza) any though on that? [1] https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp
@Honza re. what is the relation between fedora and RDO build It is Fedora rebuild, in rdo-common/mariadb we carry minimal changes to get it build in EL7 buildroot in CBS Koji + critical backports if needed, but otherwise would prefer to keep it in sync with Fedora. Until now Haikel and I were doing mostly mindless rebuilds but Michael and Damien should be taking over as actual maintainers in RDO/OSP. Digging more into details, there was a change in EL 7.3 mariadb-libs-5.5.52-1.el7 included plugins which are conflicting with mariadb-common 10.1.18 Previous version mariadb-libs-5.5.50-1.el7_2 did not include plugins, only libmysqlclient.so and there wasn't conflict. Fixing puppet-mysql is not good enough IMHO, b/c it's simple yum install mariadb which is now failing on 7.3 base image with RDO repository enabled. Also adding dependency in mariadb-server is not what we need, it's main mariadb package which needs to ensure mariadb-libs is updated.
> Another idea -- we might also do some tricks (%if %rhel...) to do things > differently in Fedora and RHEL, e.g. package the client plugins into a new > separate sub-package and this sub-package would be Required/Recommended only > in Fedora. Bad idea? I don't really like it and I think we need to solve upgrade path in Fedora too, in case somebody installs older mariadb-libs somehow?
should these files be moved to mariadb-common in *rhel* ? hence pushing that into centos and fixing the problem from the other side.
(In reply to Alan Pevec from comment #9) > I don't really like it and I think we need to solve upgrade path in Fedora > too, in case somebody installs older mariadb-libs somehow? Can you explain, please, what don't you like on that? As for the fixing upgrade path in Fedora -- I don't see a real issue there, since installing older mariadb-libs on Fedora is not what people would usually do. (In reply to Michael Bayer from comment #10) > should these files be moved to mariadb-common in *rhel* ? hence pushing > that into centos and fixing the problem from the other side. That would be definitely possible, but is it ok to wait for 7.4? (given mariadb would be updated in 7.4)
(In reply to Honza Horak from comment #11) > (In reply to Michael Bayer from comment #10) > > should these files be moved to mariadb-common in *rhel* ? hence pushing > > that into centos and fixing the problem from the other side. > That would be definitely possible, but is it ok to wait for 7.4? (given > mariadb would be updated in 7.4) Just an addition to this: when we talk about waiting we need to consider that this affects for example TripleO installations [1]. [1] https://bugs.launchpad.net/tripleo/+bug/1651713
(In reply to Honza Horak from comment #11) > Can you explain, please, what don't you like on that? I don't like %if %rhel if the change also works for Fedora. > As for the fixing upgrade path in Fedora -- I don't see a real issue there, since installing > older mariadb-libs on Fedora is not what people would usually do. Making explicit dep on the same version of mariadb-libs is still good, not sure why would we not enforce that? But if you still think this does not make sense in Fedora, we can patch it in RDO mariadb rebuild only... > (In reply to Michael Bayer from comment #10) > > should these files be moved to mariadb-common in *rhel* ? hence pushing > > that into centos and fixing the problem from the other side. > > That would be definitely possible, but is it ok to wait for 7.4? (given > mariadb would be updated in 7.4) That would be too late, we already have an issue in RDO now and next OpenStack release will be before 7.4 GA. BTW which mariadb version is planned for 7.4 ?
(In reply to Alan Pevec from comment #13) > Making explicit dep on the same version of mariadb-libs is still good, not > sure why would we not enforce that? > But if you still think this does not make sense in Fedora, we can patch it > in RDO mariadb rebuild only... It should not harm, let's try it. Has anybody tested that this change will do the trick? I'd like to be sure this is a good way before changing it. > That would be too late, we already have an issue in RDO now and next > OpenStack release will be before 7.4 GA. BTW which mariadb version is > planned for 7.4 ? Still the same, 5.5.x, we cannot update to 10.x since it is not compatible.
(In reply to Honza Horak from comment #14) > (In reply to Alan Pevec from comment #13) > > Making explicit dep on the same version of mariadb-libs is still good, not > > sure why would we not enforce that? > > But if you still think this does not make sense in Fedora, we can patch it > > in RDO mariadb rebuild only... > > It should not harm, let's try it. Has anybody tested that this change will > do the trick? I'd like to be sure this is a good way before changing it. > I've just tested on a clean CentOS7.3: # rpm -qa mariadb\* mariadb-libs-5.5.52-1.el7.x86_64 When updating specfile of mariadb-10.1.18-3.el7.x86_64.rpm to with Requires: mariadb-libs(x86-64) = 3:10.1.18-3.el7 yum install /root/rpmbuild/RPMS/x86_64/mariadb-10.1.18-3.el7.x86_64.rpm The locally patched rpm is successfully installed, after having upgraded mariadb-libs from RDO repo # rpm -qa mariadb\* mariadb-libs-10.1.18-3.el7.x86_64 mariadb-common-10.1.18-3.el7.x86_64 mariadb-10.1.18-3.el7.x86_64 mariadb-config-10.1.18-3.el7.x86_64 > > That would be too late, we already have an issue in RDO now and next > > OpenStack release will be before 7.4 GA. BTW which mariadb version is > > planned for 7.4 ? > > Still the same, 5.5.x, we cannot update to 10.x since it is not compatible.
The change is now in Fedora git: http://pkgs.fedoraproject.org/cgit/rpms/mariadb.git/commit/?id=96f19d7d3d312e35b69a3fdeb6f993aaeef69fcf Do you also need us to build the package in koji or is this enough for you and you can take it from here?
sure I'll be glad to break it :) looks like you've committed to f24, f25, master so Ill do a build for each one separately, sound good?
(In reply to Michael Bayer from comment #17) > sure I'll be glad to break it :) looks like you've committed to f24, f25, > master so Ill do a build for each one separately, sound good? I can run the build, no problem, I just didn't know whether it is necessary :) Builds are on the way now..
I know less than you :) I think we do it in fedora, then push to RDO then build in centos ?
(In reply to Michael Bayer from comment #19) > I know less than you :) I think we do it in fedora, then push to RDO then > build in centos ? I don't know either how RDO packages are built -- who picks what (srpm or source in git), when (as soon as fedora build is ready or later) and how (manually from git/koji or automatically via fedmsg).. Anyway, it does not matter much, since MariaDB builds in Fedora should be ready soon (two failed yesterday due some random test failure, re-running them now), so either way should work for you.
(In reply to Honza Horak from comment #20) > (In reply to Michael Bayer from comment #19) > > I know less than you :) I think we do it in fedora, then push to RDO then > > build in centos ? I tried to explain the process for RDO deps in comment 8 :) > I don't know either how RDO packages are built -- who picks what (srpm or > source in git), when (as soon as fedora build is ready or later) and how > (manually from git/koji or automatically via fedmsg).. It's not automated yet, it's manual rebuild from Fedora distgit but if doesn't built on EL7 we fork it lightly in http://github.com/rdo-common For mariadb there are few patches which need to be reviewed if they are still necessary: https://github.com/rdo-common/mariadb/commits/rdo-common
(In reply to Alan Pevec from comment #21) > I tried to explain the process for RDO deps in comment 8 :) I know, but it was not clear whether you take dist-git/srpm and what is the trigger. Now it is clear to me, thanks!
http://cbs.centos.org/koji/buildinfo?buildID=15275
Was fixed with https://cbs.centos.org/koji/buildinfo?buildID=15275
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days