maria-developers team mailing list archive

[Vicențiu Ciorbaru <vicentiu@xxxxxxxxxxx>]

Hi Otto!

I am doing a push towards cleaning up as much as possible from our
packaging issues. Starting with the older ones:

*Background:*
wsrep_sst_common.sh is a script that should never be run standalone, it is
rather a helper script used for other wsrep_* scripts. As such, it *does
not really belong in /usr/bin*. See MDEV-14296 [1] for more details.
<https://jira.mariadb.org/browse/MDEV-14296>

It looks like rpm packagers - read Fedora - [1a] require us to ship
wsrep_sst_common in */usr/libexec* (or alternatively /usr/share, but
/usr/libexec makes much more sense semantically to me, after reading the
FHS [2]).

There is PR #603 [3] from Daniel Black, which has some missing changes,
which I've done myself, namely updating the debian/*.install files to put
the file in the correct location and a change in path for our apparmor
profile [4] [5].

*My question for you is*: Is this acceptable to do in 10.1 (merge PR 603 +
commits [4] [5] into 10.1) from a packaging point of view?

The debian packaging policy here [6], allows one to follow FSH version 3.0
and does not mention any exception for libexec.
<https://www.debian.org/doc/debian-policy/ch-opersys.html>

I have tested this and I have not encountered any regressions while
upgrading and the script seems to function as intended (although I am not
an expert DBA to make use of wsrep_* scripts).

Thanks,
Vicențiu

[1] https://jira.mariadb.org/browse/MDEV-14296
[1a]
https://src.fedoraproject.org/rpms/mariadb/blob/ecb40d449c382ea7e4052c75d5d798734c9f7b68/f/mariadb.spec#_1303
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
[3] https://github.com/MariaDB/server/pull/603
[4]
https://github.com/MariaDB/server/commit/8042265659656c312f39304a5dc60de70876d0a1
[5]
https://github.com/MariaDB/server/commit/dbed51d86e4aae9b8a54d6b5aa31c974fe5b3479
[6] https://www.debian.org/doc/debian-policy/ch-opersys.html