Bug 999589 - Changes to make MySQL vs. MariaDB less confusing
Summary: Changes to make MySQL vs. MariaDB less confusing
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mariadb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Honza Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-21 16:03 UTC by Honza Horak
Modified: 2013-09-02 16:00 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-08-30 06:10:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1003115 0 unspecified CLOSED mariadb-libs has a file conflict with community-mysql-libs 2021-02-22 00:41:40 UTC

Internal Links: 1003115

Description Honza Horak 2013-08-21 16:03:12 UTC
Description of problem:
There is a confusion in using mariadb names somewhere and mysql somewhere else. For example package is named mariadb, but service file, daemon binary and a log file is called mysqld. On the other hand, some files like those in tmpfiles.d use mariadb. This is a proposal how to solve these confusions.

Let's use a simple rule when not sure -- what comes from upstream and is called mysql(d), it will be still called mysql*. What we provide downstream (systemd service file, log file), it will use mariadb, however we'll provide mysql alternatives for compatibility reasons when necessary.

Concrete steps (something was already done):
1) mariadb will start using /var/log/mariadb/mariadb.log by default since F20. It will solve problems with permissions when the log file is missing.
mariadb.service will be the main service file, mysqld.service will be a symlink to it (compatibility)

2) both mariadb and mysql will provide mysql-compat-server symbols, which should be used in case we don't care which package will be installed
mysql symbols shouldn't be used and they can be removed in the future (not sooner than F21)

3) mysql user will be created with /sbin/nologin as a login shell (since F20) - done

Comment 1 Honza Horak 2013-08-29 14:05:52 UTC
The above changes can introduce some issues which could be noticed by admins after upgrading to F20 in particular cases:

1) When /etc/my.cnf was edited by admin, it won't be updated by rpm after upgrading to F20 and only /etc/my.cnf.rpmnew file will be created. This will result in logging still into /var/log/mysqld.log.

In order to start to log into /var/log/mariadb/mariadb.log, admins should change log-error settings in /etc/my.cnf manually to /var/log/mariadb/mariadb.log.

2) In case logrotate script was enabled before upgrading (i.e. lines in /etc/logrotate.d/mysqld were un-commented), the logrotate script won't be removed after upgrade to F20 and logrotate will still want to rotate /var/log/mysqld.log file, which won't have to be necessary used for logging after upgrading any more (depending on log-error setting in /etc/my.cnf)

Instead, admins are advised to remove /etc/logrotate.d/mysqld and/or un-comment lines in the newly created logrotate script /etc/logrotate.d/mariadb.

Generally, admins should make sure that the logrotate script uses the same path as it is defined in /etc/my.cnf.

Comment 2 Honza Horak 2013-08-30 06:10:50 UTC
Changes above applied to F20/F21.


Note You need to log in before you can comment on or make changes to this bug.