Bug 176286 - my.cnf includes a basedir=/var/lib option that breaks installing the official RPMs
my.cnf includes a basedir=/var/lib option that breaks installing the official...
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-12-20 15:44 EST by Lenz Grimmer
Modified: 2013-07-02 23:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-09 21:44:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lenz Grimmer 2005-12-20 15:44:01 EST
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):

How reproducible:

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.

Additional info:
Comment 1 Tom Lane 2005-12-20 16:59:59 EST
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.
Comment 3 petrosyan 2008-03-09 21:44:39 EDT
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.

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