Bug #74651 | mysql-community rpms uninstall followed by reinstall changes /etc/my.cnf | ||
---|---|---|---|
Submitted: | 31 Oct 2014 15:19 | Modified: | 5 Nov 2014 9:12 |
Reporter: | Simon Mudd (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Packaging | Severity: | S3 (Non-critical) |
Version: | 5.6/5.7 | OS: | Linux (CentOS 6) |
Assigned to: | CPU Architecture: | Any | |
Tags: | community rpms, rpm, yum |
[31 Oct 2014 15:19]
Simon Mudd
[31 Oct 2014 21:13]
Terje Røsten
Hi Simon, thanks for you report. To ensure our new rpm works out of the box with default MySQL 5.6 options we have to ship a /etc/my.cnf, for example we want to push: sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES as standard in MYSQL 5.6 as an config option, ref[1]. This means we can't ship the file as %ghost as with MySQL rpms. The file is marked as config file, this means we don't overwrite the file if present on install and save the file to .rpmsave (if modified) on uninstall. This is standard rpm behaviour and what most users expect. This is also safe as it don't deletes any information from the system. Having /etc/my.cnf or /etc/mysql/my.cnf as a file as part of MySQL server package seems to be very common. One of the goals of the yum repo and rpm packaging is to be more standard compliant. With our repos we try to cover use cases most of our users wants, it's not possible to cover everything or satisfy everyone. We also provide source rpms, use for example this to download: yumdownloader --source mysql-community-server so expert users can rebuild to fit their needs better. Specs files and related files are also available in source trees in sub dirs here: https://github.com/mysql/mysql-server/tree/5.7/packaging [1]: http://dev.mysql.com/doc/refman/5.6/en/mysql-install-db.html
[1 Nov 2014 21:40]
Simon Mudd
Thanks for your explanation. My main point is the older rpms that MySQL, Sun and now Oracle have been producing and which I guess are still used by quite a lot of people have different behaviour. They have been around for at least 7 years. You introduced new rpms using a yum repository (that idea is good) just one year ago, but have also introduced a large number of changes in the way the packages work. There's been little clear public comment I'm aware of that the old style rpms are going away, nor why the changes have happened. That would be helpful so a wider audience is aware of these changes and their implications. Since 5.7.5 the development 5.7 rpms are only produced in the new format, so to evaluate them I need to take these changes into account when setting them up on my systems. Some of these changes are quite a nuisance and I've opened other tickets about this. Going forward we must move to use these rpms if the older style won't be supported. I would not mind if all the changes did not have quite as many issues as I have seen. For a small user these details probably do not matter, but when several systems are managed some of the changes that have been made are quite troublesome. This specific issue is one of them, though perhaps one of the easiest to work around. I am aware of how to download the source rpms and I have compared the way they are built as I have had to apply custom patches in the past. I have also built my own rpms for other software in the past. However, going down the path of building my own rpms involves an amount of continued extra work and testing which is something I would rather avoid. I guess I will have to find out how others manage their installations in such a way that these are not issues for them and learn from them.
[5 Nov 2014 9:12]
MySQL Verification Team
Hello Simon, Thank you for the report and feedback. Thanks, Umesh
[20 May 2016 8:31]
Terje Røsten
Hi Simon, it's hard to see an other fix than documenting change in behaviour. What do you think about this issue, now when you have used 5.7 rpms for a while?