Bug #72230 Undesirable MySQL yum repo packaging dependencies
Submitted: 3 Apr 2014 21:44 Modified: 11 May 2016 20:33
Reporter: Simon Mudd (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Package Repos Severity:S3 (Non-critical)
Version:5.7.4,5.6.19,5.7.12,5.7 OS:Linux (CentOS 6/7)
Assigned to: Terje Røsten CPU Architecture:Any
Tags: centos6, CentOS7

[3 Apr 2014 21:44] Simon Mudd
Description:
I thought I'd upgrade my home machine to use 5.7.4 but notice that when trying to upgrade the server package using the "yum repo" community version this triggers an update of the client and also other related packages.

I'm using this repo definition:

# Note: MySQL 5.7 is currently in development. For use at your own risk.
# Please read with sub pages: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/
[mysql57-community-dmr]
name=MySQL 5.7 Community Server Development Milestone Release
baseurl=http://repo.mysql.com/yum/mysql-5.7-community/el/6/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:/etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

This behaviour is not really desirable.  In my current case that might be fine, but the added dependencies seem to indicate an inability to upgrade for example the library, client or server packages independently which in a more production like environment might be necessary for a variety of reasons.

The behaviour also seems to differ from the original RPM packages for RHEL 6/CentOS 6 which can be found http://dev.mysql.com/downloads/mysql, where the MySQL-server or MySQL-client packages are self-contained and do not pull in extra "common packages".

How to repeat:
$ rpm -qa | grep -i mysql
mysql-community-client-5.7.3-0.1.m13.el6.x86_64
mysql-workbench-community-6.0.8-1.el6.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
mysql-community-server-5.7.3-0.1.m13.el6.x86_64
mysql-connector-python-1.1.4-1.el6.noarch
mysql-community-common-5.7.3-0.1.m13.el6.x86_64
mysql-community-libs-compat-5.7.3-0.1.m13.el6.x86_64
qt-mysql-4.6.2-26.el6_4.x86_64
mysql-utilities-1.4.1-1.el6.noarch
mysql-community-release-el6-5.noarch
php-mysql-5.3.3-27.el6_5.x86_64
mysql-community-libs-5.7.3-0.1.m13.el6.x86_64
$ sudo yum --disablerepo=* --enablerepo=mysql57-community-dmr update mysql-community-server
Loaded plugins: fastestmirror, presto
Loading mirror speeds from cached hostfile
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package mysql-community-server.x86_64 0:5.7.3-0.1.m13.el6 will be updated
---> Package mysql-community-server.x86_64 0:5.7.4-0.3.m14.el6 will be an update
--> Processing Dependency: mysql-community-common(x86-64) = 5.7.4-0.3.m14.el6 for package: mysql-community-server-5.7.4-0.3.m14.el6.x86_64
--> Processing Dependency: mysql-community-client(x86-64) = 5.7.4-0.3.m14.el6 for package: mysql-community-server-5.7.4-0.3.m14.el6.x86_64
--> Running transaction check
---> Package mysql-community-client.x86_64 0:5.7.3-0.1.m13.el6 will be updated
---> Package mysql-community-client.x86_64 0:5.7.4-0.3.m14.el6 will be an update
--> Processing Dependency: mysql-community-libs(x86-64) = 5.7.4-0.3.m14.el6 for package: mysql-community-client-5.7.4-0.3.m14.el6.x86_64
---> Package mysql-community-common.x86_64 0:5.7.3-0.1.m13.el6 will be updated
---> Package mysql-community-common.x86_64 0:5.7.4-0.3.m14.el6 will be an update
--> Running transaction check
---> Package mysql-community-libs.x86_64 0:5.7.3-0.1.m13.el6 will be updated
---> Package mysql-community-libs.x86_64 0:5.7.4-0.3.m14.el6 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================================================================================================
 Package                                                        Arch                                           Version                                                   Repository                                                     Size
=============================================================================================================================================================================================================================================
Updating:
 mysql-community-server                                         x86_64                                         5.7.4-0.3.m14.el6                                         mysql57-community-dmr                                          65 M
Updating for dependencies:
 mysql-community-client                                         x86_64                                         5.7.4-0.3.m14.el6                                         mysql57-community-dmr                                          20 M
 mysql-community-common                                         x86_64                                         5.7.4-0.3.m14.el6                                         mysql57-community-dmr                                         299 k
 mysql-community-libs                                           x86_64                                         5.7.4-0.3.m14.el6                                         mysql57-community-dmr                                         2.1 M

Transaction Summary
=============================================================================================================================================================================================================================================
Upgrade       4 Package(s)

Total download size: 88 M
Is this ok [y/N]:
...

Suggested fix:
I have not looked at the packaging differences between the original RPMs and the new community ones that Oracle is providing but think that it would be better to change things:

1. The server package should NOT have library dependencies on other mysql rpms at least not on a _specific_ version.  So requiring mysql-community-libs or mysql-community-common may be ok (and for any 5.7.X) but mysql-community-server-5.7.X should not depend on mysql-<whatever>-5.7.X too, as upgrading one package forces you to upgrade others.

2. There should not be a dependency on the client package, though I'm guessing the client dependency upgrade is due to the library/common upgrades. So this issue may go away if you solve (1) above.

I am planning, once 5.7 goes GA, on moving to this new repo because it will be easier to download and upgrade packages as they are released, but behaviour like the above is something which might make me reconsider that unless of course you drop support for MySQL 5.7 (GA) from http://dev.mysql.com/downloads/mysql and there is no other choice. (It is now being offered as a development version.)

It is appreciated that you provide MySQL rpm packages, and this new yum repo but the packaging decisions which are made sometimes surprise me and seem to change without any obvious reason or explanation.
[4 Apr 2014 10:26] MySQL Verification Team
Hello Simon,

Thank you for the bug report.
Verified as described.

Thanks,
Umesh
[31 Jul 2014 7:13] Simon Mudd
A similar issue exists now with the GA version of MySQL 5.6 on the new RHEL7/CentOS 7.
[30 Sep 2014 18:12] MySQL Verification Team
mysql-community-server for CentOS 6 has these dependencies:

==========================================================================================================
 Package                         Arch            Version                 Repository                  Size
==========================================================================================================
Installing:
 mysql-community-server          x86_64          5.6.21-2.el6            mysql56-community           53 M
Installing for dependencies:
 mysql-community-client          x86_64          5.6.21-2.el6            mysql56-community           18 M
 mysql-community-common          x86_64          5.6.21-2.el6            mysql56-community          299 k
 mysql-community-libs            x86_64          5.6.21-2.el6            mysql56-community          1.9 M
[31 Oct 2014 11:32] Simon Mudd
See also: http://bugs.mysql.com/bug.php?id=74648
[10 May 2016 8:34] Simon Mudd
I reported this 2 years ago and am suffering from the issues it generates.
At that time 5.7 was a DMR version so a test system and it was not used in production, so I put up with the pain.
When I initially reported this I was (and still am) using the MySQL-server/client 5.6 rpms that were not part of your "yum packaging" so I was not affected.
Now I am moving over to 5.7 and still want to use rpm/yum as the OS I'm using has this as it's underlying package manager.

I now have quite a large number of production servers running 5.7.9, 5.7.10, 5.7.11 and 5.7.12.
Some of these boxes are in clusters where in theory I want to have exactly the same version running.

I'd like to be able to have the "latest" client rpms running.
* Maybe it makes no difference but if there's an updated 5.7 client why not use it.
* The same appies for the libs and libs-compat packages (used by other packages on my system) which don't care what version the server is running.

I can not shut down all my servers at once, upgrade to 5.7.12 (current GA version) and carry on happily. Bugs occur and I need to check stuff prior to doing that.

So right now the automated rules for upgrading the server package have to be tied with those for upgrading the client/library packages and this really should not be necessary. 

Others have suggested that I just give up with rpms and use tarballs and do it all myself. I guess I could do that but rpm and yum _are_ package managers. The idea is that they make my life easier not harder to manage and currently that's not the case.

I have to some extent worked around this. I know how to "squeeze past" the limitations which are currently imposed on me but they are a major nuisance.

It was suggested to me that this dependency setup was done deliberately as it is "better". Maybe it is simpler or better for someone who has MySQL running on their laptop, who stops and start the server whenever they want but the forced dependency bindings between  all the packages is a huge pain when you run multiple major and minor versions of MySQL on different servers.

The problem report is "verified" so you are aware of it

I would be interested to know whether this will ever be addressed or the current dependency management is intended to stay this way. Knowing the answer to that will allow me to decide how to proceed.
[11 May 2016 13:12] Paul DuBois
Posted by developer:
 
Noted in 5.7.13 changelog.

Previously, upgrading the server using an RPM package (including
installation using yum) required upgrading the client package to the
same MySQL version, which may be undesirable for some installations.
This rule has been relaxed so that upgrading to a General
Availability (GA) server version requires only that some GA client
version be installed, which is less likely to require a client
upgrade.
[11 May 2016 20:33] Simon Mudd
Thanks very much for addressing this.
[27 Sep 2016 14:30] Terje Røsten
Posted by developer:
 
That's due to:  

 BUG#23338603 NEW SERVER INACTIVE AFTER UPGRADING ONLY SERVER PACKAGE FROM 5.7.9

Turns out mysqld requires the exact version of /usr/share/mysql/english/errmsg.sys to work,
as /usr/share/mysql/english/errmsg.sys is in -common package, we must have strict dep between
-server and -common package.