[debian-mysql] my.cnf in mysql-server instaed of mysql-common

Monty Taylor monty at inaugust.com
Tue Feb 19 11:33:33 UTC 2008


Christian Hammers wrote:
> On Mon, 18 Feb 2008 21:36:45 -0300
> Monty Taylor <monty at inaugust.com> wrote:
> 
>> Hey all,
>>
>> Why do we put my.cnf in mysql-common? It seems to me that it's only
>> relevant if you have the server installed. Client libs don't need it to
>> tell them where the local server is if there is no local server
>> installed...
>>
>> Is there some other reason I'm missing?
> 
> Back then I did it because of those entrie here:
> 	[mysqldump]
> 	quick
> 	quote-names
> 	max_allowed_packet      = 16M
> 	
> 	[mysql]
> 	#no-auto-rehash # faster start of mysql but no tab completition
> 	
> 	[isamchk]
> 	key_buffer              = 16M
> 

Ah, ok.

>> The existence of that file on systems where mysql-server hasn't been
>> installed seems to cause _GREAT_PAIN_ to many of the MySQL folks who
>> like to install mysql via binary tarball instead (usually because they
>> need to install multiple concurrent versions for testing purposes...)
>>
>> If there isn't a reason, would it be permissable to move the file to
>> mysql-server?
> 
> I have one server with binary tarball. It looks for /etc/my.cnf so I
> just symlinked that to /etc/mysql/my.cnf. Debian Clients also
> look there and can access the MySQL binary server without problems.
> 
> If I wanted to run multiple binaries I would have to pass separate configs
> to each of them anyway.
> 
> So I don't see the problem right now...

Well, mysql looks in /etc/mysql/my.cnf by default now too. So they don't
install any mysql packages,  but mysql-common probably gets installed
due to a depend somewhere, and then then install their tarball and all
of a sudden it's reading settings that they aren't expecting.



More information about the pkg-mysql-maint mailing list