Bug 176286

Summary:	my.cnf includes a basedir=/var/lib option that breaks installing the official RPMs
Product:	[Fedora] Fedora	Reporter:	Lenz Grimmer <lenz>
Component:	mysql	Assignee:	Tom Lane <tgl>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	byte, hhorak
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://forums.mysql.com/read.php?11,56021,56021#msg-56021
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-10 01:44:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lenz Grimmer 2005-12-20 20:44:01 UTC

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:

[mysql.server]
basedir=/var/lib

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:
Always

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 21:59:59 UTC

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-10 01:44:39 UTC

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.