[debian-mysql] my.cnf problems

[Norvald H. Ryeng]

On Tue, 10 Dec 2013 01:34:15 +0100, Stewart Smith  
<stewart.smith at percona.com> wrote:

> "Norvald H. Ryeng" <norvald.ryeng at oracle.com> writes:
>> On Sat, 07 Dec 2013 03:10:07 +0100, Clint Byrum <spamaps at debian.org>  
>> wrote:
>>
>>> Excerpts from Bjoern Boschman's message of 2013-12-06 06:01:19 -0800:
>>>> Hi folks,
>>>>
>>>> I've seen some blockers due to the fact that everybody (mysql, maria,
>>>> percona) includes my.cnf from mysql-common.
>>>>
>>>> my 2 cent:
>>>>
>>>> maria: /etc/mariadb/my.cnf
>>>> mysql: /etc/mysql/my.cnf
>>>> percona: /etc/percona/my.cnf
>>>>
>>>> From my point of view it's a dream that cannot be fullfilled that all
>>>> forks can share the same configuration file.
>>>>
>>>
>>> This dream is one propagated by all three. They hard code /etc/mysql
>>> everywhere.
>>
>> Actually, I think the path is defined only once, in
>> init_default_directories() in mysys. MySQL already looks for
>> /etc/mysql/my.cnf if there is no /etc/my.cnf. If Percona and MariaDB do
>> something similar, the problem is solved by not having /etc/my.cnf.
>>
>>> This is complicated further by libmysqlclient also hard coding the  
>>> path.
>>
>> AFAIK, it uses the same mysys function.
>
> It does.
>
> Actually... there's an idea... if we had the PS/Maria specific options
> in a PS/Maria specific config group, we could have PS and Maria load
> those groups, MySQl wouldn't and as long as the PS/Maria option didn't
> change on disk compatibility, we'd probably be just fine.
>
> This is, of course, assuming that PS and Maria accept every new MySQl
> config option at least as a no-op.

That sounds like a viable solution. Is this something that is already  
supported by PS?

Regards,

Norvald