| Bug #70985 | mysql-community-server should not depend on mysql-community-client | ||
|---|---|---|---|
| Submitted: | 23 Nov 2013 8:24 | Modified: | 3 Dec 2013 16:24 |
| Reporter: | Simon Mudd (OCA) | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: Packaging | Severity: | S3 (Non-critical) |
| Version: | 5.6.14 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[23 Nov 2013 8:24]
Simon Mudd
[23 Nov 2013 9:43]
Simon Mudd
This is the output from your older "non yum repo" packages: # rpm -qa | grep MySQL MySQL-shared-compat-5.6.13-1.el6.x86_64 MySQL-client-5.6.13-1.el6.x86_64 MySQL-server-5.6.13-1.el6.x86_64 # rpm -e MySQL-client # yum install MySQL-client # my my own yum repo Loaded plugins: fastestmirror, priorities, puppet ... Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package MySQL-client.x86_64 0:5.6.14-1.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Installing: MySQL-client x86_64 5.6.14-1.el6 mysql-stable 18 M Transaction Summary =================================================================================================================================================================================================================== Install 1 Package(s) Total download size: 18 M Installed size: 81 M Is this ok [y/N]: y Downloading Packages: MySQL-client-5.6.14-1.el6.x86_64.rpm | 18 MB 00:01 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Warning: RPMDB altered outside of yum. Installing : MySQL-client-5.6.14-1.el6.x86_64 1/1 Verifying : MySQL-client-5.6.14-1.el6.x86_64 1/1 Installed: MySQL-client.x86_64 0:5.6.14-1.el6 Complete! # rpm -q centos-release centos-release-6-3.el6.centos.9.x86_64
[23 Nov 2013 9:44]
Simon Mudd
So as you can see the old packages do not require the client package to be installed, whereas the new ones do. It may be normal to have both server and client packages installed on a server but it shouldn't be a requirement. Whatever is needed to install the server should be in the server package.
[24 Nov 2013 16:26]
Terje Røsten
There are two separated issues here. The first issue is if server package should depend on client package. The second issue is whether different versions of client and server package should be allowed to be installed in the same location or basedir (/usr for rpm packages). It's important to remember that MySQL Server is developed as whole system: server, client, embedded server and client libs are in same source tree. All these components are tested together. They also share the common files in the directory /usr/share/mysql and config file /etc/my.cnf. There are also other bindings between server and client. MySQL 5.6 Server introduce the expired password feature. To reset password for an expired account a MySQL 5.6 client is needed. mysqld_safe, used to start and stop the server, depend on utility mysql_config. mysql_config is in the client package. It make sense for client and client library not to depend on server package, however they indeed depend on mysql-community-common, which contains files in /usr/share/mysql. A splitting into several packages is useful in this regard. Some Linux distributions ships /etc/my.cnf and /usr/share/mysql files in the client library package. This means a conflict between mysql-community-server package from MySQL Yum Repository and mysql-libs package from distribution vendor. Due to this, a natural command as: $ yum mysql-community-server will not work. There are lots of conflicts when server not depend on any other mysql-community package. When mysql-community-server depend on client package (which in turn depend on libs and common package), this conflict between mysql-libs from vendor and MySQL Yum Repository will be removed and the natural command will indeed work. The same issue will show up if you remove mysql-community-client by using $ rpm -e --nodeps mysql-community-client (not recommended) and try to install mysql client package from vendor. This package requires mysql-libs which will have lots of conflicts with mysql-community-server or mysql-community-common (needed by server) packages. On this background we decided to let server package depend on client package of exactly the same version and release (built in the same process). Covering the most common scenarios for users of MySQL Yum Repository. Source rpms are available if you what to rebuild a modified package. An workaround for bug #70958 (untill fixed) would be to use a parallel install of an older MySQL client. You can e.g. use the Compressed TAR Archive option from https://dev.mysql.com/downloads/mysql/5.1.html#downloads
[25 Nov 2013 7:13]
Simon Mudd
Terje: thanks for your comments, but why then have the MySQL packages you have been building up until now not worked this way? They have been working "fine" for > 6 years and now you suddenly start to change the way this new set of packages behaves. In previous blog post I have requested that you guys explain the thinking behind why you build packages a certain way as this seems to change periodically an that breaks stuff which then takes a long time to get fixed. You will probably be aware of rpm packaging bug reports I have made for MySQL packages in the past for packages made by MySQL, Sun and now Oracle. Most of these have been due to sudden changes in packaging behaviour and have triggered significant pain to me as your packages are used on a number of systems. You mention the 2 issues which I agree with. (a) whether the server package should depend on the client package (b) whether multiple versions of MySQL should be installed on the server server at the same time. This bug report came up because of bug#70958 which obliges me to use a lower version of MySQL to access a "production server" which unfortunately runs 5.0.95. Yes, an old version but the version provided on CentOS 5 which is a production version of CentOS/RHEL/OEL. I do not control that server but do need to use the older client packages. Related to (b) I have reported to Oracle/Sun/MySQL support staff on a number of occasions the problems caused by only allowing the user to install a single version of MySQL. Please check with your colleagues. It is impossible to run mysql_check with a new binary on an old running MySQL server in order to see any issues which may come up prior to upgrading. Bug#70958 also lead me to want to use an older version of the client and indeed if you need to access a remote server you may need a different version to the version the server runs. So the need to have flexibility of which client package to install is clear. This also worked before as "Current" MySQL-server packages have never had a dependency on MySQL-client packages, so the change to the new behaviour is not consistent and certainly unexpected. Note: the biggest issue for all of this is that most of the time you can not stop the database server and this should be considered as a single unique element. Having dependencies on other packages, even if they are MySQL packages just makes things more complex. I'd suggest that the mysql server package have ALL mysql libraries statically linked into the binary. This should be done deliberately to avoid dependencies outside of the package itself. Personally I would like to be able to have multiple MySQL -server or client versions installed at once. That would mirror what "Oracle" or Sybase does even if it does not follow perhaps the most "normal" rpm setup. MySQL is not the only package which needs multiple versions and indeed kernel packages have always been setup this way. My vision in this case would be to install binaries under a directory like /.../mysql-<version>/ .... and to use the alternates mechanism to choose one of the packages as the default which you would access like now. While I do not currently run multiple mysql instances on the same server, a lot of people do, and this is impossible with the current mysql packaging configuration. You arguments for the current mechanism do not really convince me and the comment about what other distributions do does not seem that valid if you have been providing MySQL packages for RHEL and derivates a certain way for a long time. So I appreciate you giving feedback on your reasoning but am not convinced that these changes are good.
[3 Dec 2013 16:24]
Sveta Smirnova
Thank you for the report. Verified as described: $ rpm -qpR mysql-community-server-5.6.14-3.el6.x86_64.rpm ... mysql-community-client(x86-64) = 5.6.14-3.el6 mysql-community-common(x86-64) = 5.6.14-3.el6 ... And I totally agree with you: there are can be tons of scenarios and setups when it is needed and even more safe to have server alone installed.
[3 Dec 2013 16:25]
Sveta Smirnova
Packages from dev.mysql.com/downloads are not affected: $ rpm -qpR MySQL-server-5.6.15-1.el6.x86_64.rpm | grep -i mysql config(MySQL-server) = 5.6.15-1.el6
