Should MariaDB touch my.cnf in %post?

[Honza Horak]

Hi folks,

I'd like to share an idea related to MySQL->MariaDB move, that may be a 
bit controversial. Speaking about default case in Fedora, MySQL has used 
only one file at /etc/my.cnf to configure server, libraries, 
command-line utilities, etc.

MariaDB uses by default /etc/my.cnf and 
/etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d 
directory is included using !includedir statement in /etc/my.cnf.

The problem is, that after replacing MySQL with MariaDB existed my.cnf 
won't get updated (uses "%config(noreplace)") and then users will be 
confused by having /etc/my.cnf.d/* files, which won't be used.

A solution proposed by MariaDB upstream would be adding !includedir 
directive into /etc/my.cnf (if not already done) in mariadb's %post 
section. That would mean *modifying user's configuration during RPM update*.

I haven't found any restriction forbidding this solution, but would like 
to collect opinions, how bad it is, because we're aware it's not very 
clean -- however, it has it's benefits.

In case user won't wish to use !includedir anymore, he'd comment it out 
and it won't get added again.

Cheers,
Honza

[Reindl Harald]

Am 12.02.2013 18:46, schrieb Honza Horak:
>  I'd like to share an idea related to MySQL->MariaDB move, that
> may be a bit controversial. Speaking about default
>  case in Fedora, MySQL has used only one file at /etc/my.cnf to configure server,
> libraries, command-line utilities,
>  etc.
>  
>  MariaDB uses by default /etc/my.cnf and /etc/my.cnf.d/{client,server,..}.cnf files, while
> all the /etc/my.cnf.d
>  directory is included using !includedir statement in /etc/my.cnf.
>  
>  The problem is, that after replacing MySQL with MariaDB existed my.cnf won't get
> updated (uses
>  "%config(noreplace)") and then users will be confused by having /etc/my.cnf.d/*
> files, which won't be used.
>  
>  A solution proposed by MariaDB upstream would be adding !includedir directive into
> /etc/my.cnf (if not already
>  done) in mariadb's %post section. That would mean *modifying user's configuration
> during RPM update*.
>  
>  I haven't found any restriction forbidding this solution, but would like to collect
> opinions, how bad it is,
>  because we're aware it's not very clean -- however, it has it's benefits.
>  
>  In case user won't wish to use !includedir anymore, he'd comment it out and it
> won't get added again. 
please do not touch /etc/my.cnf

any real used mysqld will have a customized /etc/my.cnf and no admin
should do this migartion without take really care what happens and
test this before - unclean soltutions will hurt sooner or later
in moments where this is not expected

[Toshio Kuratomi]

On Tue, Feb 12, 2013 at 06:46:28PM +0100, Honza Horak wrote:
>  Hi folks,
>  
>  I'd like to share an idea related to MySQL->MariaDB move, that may be
>  a bit controversial. Speaking about default case in Fedora, MySQL has
>  used only one file at /etc/my.cnf to configure server, libraries,
>  command-line utilities, etc.
>  
>  MariaDB uses by default /etc/my.cnf and
>  /etc/my.cnf.d/{client,server,..}.cnf files, while all the
>  /etc/my.cnf.d directory is included using !includedir statement in
>  /etc/my.cnf.
>  
>  The problem is, that after replacing MySQL with MariaDB existed
>  my.cnf won't get updated (uses "%config(noreplace)") and then users
>  will be confused by having /etc/my.cnf.d/* files, which won't be
>  used.
>  
>  A solution proposed by MariaDB upstream would be adding !includedir
>  directive into /etc/my.cnf (if not already done) in mariadb's %post
>  section. That would mean *modifying user's configuration during RPM
>  update*.
>  
>  I haven't found any restriction forbidding this solution, but would
>  like to collect opinions, how bad it is, because we're aware it's not
>  very clean -- however, it has it's benefits.
>  
>  In case user won't wish to use !includedir anymore, he'd comment it
>  out and it won't get added again.
>   
Bad idea.

There are several reasons that user's config files shouldn't be touched:

* Possibility of getting the change to the user's config wrong is very high
  as user's can change their config in arbitrary ways.  Do you handle the
  case where a user has added their own includedirs?  Do you handle the case
  where a user has commented out their own includedir?  Do you handle the
  case where a user has a comment about includedir?  Do you handle the case
  where a user has deleted the includedir line?  There are many corner cases
  that can be missed here.
* User expectation is currently that their configs aren't going to change on
  version upgrade.  Instead, they need to look for .rpmnew and .rpmsave
  files to tell them if anything has changed that they need to be aware of.
  A user updating to F19 won't be expecting that files in /etc/my.cnf.d
  should affect their installation if they didn't have to migrate that over
  from the my.cnf.rpmnew file themselves.

be sure to add this change and how upgraders should handle it to the release
notes :-)

-Toshio

[Michal Hlavinka]

On 02/12/2013 06:46 PM, Honza Horak wrote:
>  Hi folks,
>
>  I'd like to share an idea related to MySQL->MariaDB move, that may be a
>  bit controversial. Speaking about default case in Fedora, MySQL has used
>  only one file at /etc/my.cnf to configure server, libraries,
>  command-line utilities, etc.
>
>  MariaDB uses by default /etc/my.cnf and
>  /etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d
>  directory is included using !includedir statement in /etc/my.cnf.
>
>  The problem is, that after replacing MySQL with MariaDB existed my.cnf
>  won't get updated (uses "%config(noreplace)") and then users will be
>  confused by having /etc/my.cnf.d/* files, which won't be used. 
Just add README file to /etc/my.cnf.d/ mentioning that /etc/my.cnf must 
contain that includedir line or those file won't be used

Michal