[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