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: | |
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
[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.