Red Hat Bugzilla – Bug 176286
my.cnf includes a basedir=/var/lib option that breaks installing the official RPMs
Last modified: 2013-07-02 23:07:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051128 SUSE/1.5-0.1 Firefox/1.5
Description of problem:
The MySQL RPMs as shipped with Fedora Linux seem to install an /etc/my.cnf file by default, which seems to include the following option:
This line causes the startup of MySQL to fail, when a user updates to the RPMs provided by MySQL AB (as the RPM update will keep the my.cnf file in place). As this option should not really be necessary, it would be great if it could be removed. This would help us to resolve one of the major problems users of Fedora Linux have when using our RPMs.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora Linux with the included version of MySQL
2. Download MySQL RPMs from dev.mysql.com and install them using "rpm -U"
3. Try to start the server by using /etc/init.d/mysql start and observe the error
Actual Results: MySQL fails to start up
Expected Results: The MySQL init script should have started the server.
Why is that particular line a problem, and not any of the other ones in the
standard my.cnf? Is there any point in worrying about this when the user could
have changed my.cnf in other ways that might also break another RPM?
Since the RH RPMs must also say %config(noreplace) for this file, any change I
make is going to have a heck of a long lead time before it impacts the average
installation in the field. I think it'd be better to find a way to coexist
without expecting a change in the file contents ...
BTW, there are Conflicts: lines in the RH specfile that I thought were supposed
to prevent this sort of problem by disallowing concurrent installation of RH's
RPMs with MySQL AB's RPMs. Is that not working for some reason? I'd have
expected the user to have to remove ours first, which should have made things
work according to the discussion in the cited URL.
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.