MariaDB 1.3.27 overwrites customized my.cnf

[Miroslav Lachman]

Am I the only one who sees this (critical) problem after upgrade from 
MariaDB 10.3.23 to newer version (10.3.25 or 10.3.27)?

There is our customized fine-tuned /usr/local/etc/my.cnf for years 
untouched by pkg install or pkg upgrade. After the last pkg upgrade 
MariaDB cannot (re)start because my.cnf was replaced with some generic 
file which contains this:

#
# This group is read both by the client and the server
# use it for options that affect everything
#
[client-server]

#
# include *.cnf from the config directory
#
!includedir /usr/local/etc/mysql/conf.d


But the directory /usr/local/etc/mysql/conf.d is empty. If something 
silently replaces my config file I would expect it to move my file to 
proper location which is not the case. My file is simply replaced and 
configuration of MariaDB is lost and daemon cannot be (re)started any 
more. I think this is POLA, should be mentioned in UPDATING and pkg-message.
The only way to make it work again is restore my.cnf from backup.

I filled  bug report as PR 251550
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251550

It seems really critical to me but I am surprised nobody else reported this.

This is on FreeBSD 11.4 amd64 with packages built in our Poudriere

Options        :
         CONNECT_EXTRA  : off
         DOCS           : off
         GSSAPI_BASE    : off
         GSSAPI_HEIMDAL : off
         GSSAPI_MIT     : off
         GSSAPI_NONE    : on
         INNOBASE       : on
         LZ4            : on
         LZO            : on
         MROONGA        : off
         MSGPACK        : off
         OQGRAPH        : off
         ROCKSDB        : off
         SNAPPY         : off
         SPHINX         : on
         SPIDER         : on
         TOKUDB         : off
         WSREP          : on
         ZMQ            : off
         ZSTD           : off

Kind regards
Miroslav Lachman