MDEV-14296: Relocate wsrep_sst_common from /usr/bin to /usr/share/mariadb

[FaramosCZ]

wsrep_sst_common is a bash function library (no shebang, only function definitions and shared variables) that is sourced by other wsrep_sst_* scripts. Unlike those scripts, it is not an executable and should not reside in /usr/bin. This commit moves it to the shared data directory (INSTALL_MYSQLSHAREDIR, typically /usr/share/mariadb on RPM/DEB systems), which is the standard location for architecture-independent data files.

New install path: ${INSTALL_MYSQLSHAREDIR}/wsrep_sst_common

• RPM layout: /usr/share/mariadb/wsrep_sst_common
• DEB layout: /usr/share/mariadb/wsrep_sst_common
• Standalone layout: /share/wsrep_sst_common

Files modified:

scripts/CMakeLists.txt
- Changed INSTALL(FILES ...) destination from ${INSTALL_BINDIR} to ${INSTALL_MYSQLSHAREDIR} for the WSREP_SOURCE (wsrep_sst_common).
- Updated comment to explain the rationale for the non-bindir location.

scripts/wsrep_sst_backup.sh
scripts/wsrep_sst_mariabackup.sh
scripts/wsrep_sst_mysqldump.sh
scripts/wsrep_sst_rsync.sh
- Updated the source command to locate wsrep_sst_common. The new logic first checks the script's own directory (for build-tree / MTR test compatibility, where all scripts are generated into the same build directory), and falls back to the CMake-substituted installed path (@INSTALL_MYSQLSHAREDIRABS@) when the file is not found alongside the calling script.

support-files/policy/apparmor/usr.sbin.mysqld
- Updated AppArmor read permission from /usr/bin/wsrep_sst_common to /usr/share/mariadb/wsrep_sst_common.

debian/mariadb-server.install
- Updated Debian package file list entry from usr/bin/wsrep_sst_common to usr/share/mariadb/wsrep_sst_common.

[gkodinov]

Thank you for your contribution. This is a preliminary review.

LGTM.

Please stand by for the final review.

[grooverdan]

Ok. aside from the selinux question I'm ok with this.

Minor but resolvable conflict with #4644.

This PR highlight I may have made a mistake on the script components. Very timely. I'll leave as mergable as posisble.

[grooverdan]

Sorry for being rightfully suspicious about mysql-selinux needing an update.

While I looked at this I notice I did some thing wrong hence #4923.

With the version bumped mysql-selinux + #4923 this would become a dependency in cmake/cpack_rpm.cmake:

IF(RPM MATCHES "fedora|rhel|centos" AND NOT RPM MATCHES "rhel[78]")
  SETA(CPACK_RPM_server-galera_PACKAGE_REQUIRES "(mysql-selinux  >= 1.0.16 if selinux-policy-targeted)")
ENDIF()

If its possible to get into Fedora/RHEL/Centos by 2026-05-08, the planned 12.3.2 release date we could make this a bug fix against 12.3. If a user was really desperate is a dnf localinstall of the Fedora mysql-selinux package on RHEL an actual solution? (though a local copy of the common file back to /usr/bin may be cleaner).

So up to you:

• get mysql-selinux-1.0.16 released, and wait for MDEV-30953: Add MariaDB-server-galera (RPM) fix #4923 merged, rebase this to 12.3 (accounting for the wsrep_sst_common becoming part of mariadb-server-galera.install in Deb.
• wait on a merge up to main and then rebase this there, conflict resolve + the dependency

[FaramosCZ]

If a user was really desperate is a dnf localinstall of the Fedora mysql-selinux package on RHEL an actual solution? (though a local copy of the common file back to /usr/bin may be cleaner).

AFAIK yes.

If its possible to get into Fedora/RHEL/Centos by 2026-05-08, the planned 12.3.2 release date

That's OK for Fedora but not by far for RHEL.
So it's definitely safer to target main.

--

In Fedora it just landed to Rawhide.