MDEV-30953: mariadb-server-galera package

[grooverdan]

The ldd differences need to account that
this is a new 12.3 package.

MDEV-30953, currently being prototyped on bb-12.3-MDEV-30953-mariadb-server-galera-pkgtest ci.

needs to normalise to expectations for https://buildbot.mariadb.org/#/builders/784/builds/1861/steps/4/logs/stdio

-=== /usr/lib/mysql/plugin/wsrep_info.so
-	/lib/ld-linux-aarch64.so.1 
-	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 
-	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 
-	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 
-	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 
-	libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 
-	linux-vdso.so.1 

and

--- ./plugins.old.cmp	2026-03-13 03:51:08.520277534 +0000
+++ ./plugins.new.cmp	2026-03-13 03:51:08.516277442 +0000
@@ -69,8 +69,6 @@
 THREAD_POOL_STATS	ACTIVE	INFORMATION SCHEMA	NULL	GPL
 THREAD_POOL_WAITS	ACTIVE	INFORMATION SCHEMA	NULL	GPL
 USER_STATISTICS	ACTIVE	INFORMATION SCHEMA	NULL	GPL
-WSREP_MEMBERSHIP	NOT INSTALLED	INFORMATION SCHEMA	wsrep_info.so	GPL
-WSREP_STATUS	NOT INSTALLED	INFORMATION SCHEMA	wsrep_info.so	GPL
 associative_array	ACTIVE	DATA TYPE	NULL	GPL
 binlog	ACTIVE	DAEMON	NULL	GPL
 ed25519	NOT INSTALLED	AUTHENTICATION	auth_ed25519.so	GPL

I haven't yet found rpm example. Other server bugs in Columnstore (that are reported) preventing this output to be visible.

Obvious for test env testing. But suggestions on better ways most welcome.

[grooverdan]

The ldd changes need to be non-greedy.

[grooverdan]

reconsidering the last wsrep_info handling. I think I've resolved it server side.

First commit only of importance now.

https://buildbot.mariadb.org/#/grid?branch=bb-12.3-MDEV-30953-mariadb-server-galera-pkgtest

[grooverdan]

I've attempted to account for all the things from https://buildbot.dev.mariadb.org/#/grid?branch=bb-MDEV-38913-pkgtest

I had troubles with local tests:

~/repos/mariadb-buildbot MDEV-30953
$ podman run --rm --entrypoint /usr/lib/systemd/systemd --user root -v ./scripts:/scripts/ --name u2510 quay.io/mariadb-foundation/bb-worker:dev_ubuntu25.10 --system

$ podman exec -ti --user root -w /scripts  u2510 bash
root@66e2e18e5e64:/scripts# apt-get install -y jq
root@66e2e18e5e64:/scripts# ./deb-upgrade.sh https://buildbot.dev.mariadb.org/#/builders/448/builds/16
...
+ get_columnstore_logs
+ [[ all == \c\o\l\u\m\n\s\t\o\r\e ]]
+ bb_log_err 'mariadb service didn'\''t start properly after installation'
+ set +x
ERROR: mariadb service didn't start properly after installation

Hacked

diff --git a/scripts/deb-upgrade.sh b/scripts/deb-upgrade.sh
index 06fef2a..f538ffa 100755
--- a/scripts/deb-upgrade.sh
+++ b/scripts/deb-upgrade.sh
@@ -146,8 +146,8 @@ if [[ $systemdCapability == "yes" ]]; then
     sudo journalctl -xe --no-pager
     get_columnstore_logs
     bb_log_err "mariadb service didn't start properly after installation"
-    exit 1
   fi
+  systemctl start mariadb.service
 fi

Waiting for rebased build to build with bumped version number.

[RazvanLiviuVarzaru]

My take:

1. It is a hard requirement for all of our container environments to have galera-4 installed for the mariadb-galera-package to be produced? I hope not, because the process of updating the container images with galera-4 is async, meaning first we have the autobake builders then we are able to embedd galera-4 from ci.mariadb.org on a second container image build. (but not before we re-trigger all the galera builds to include the new OS)

If I correctly understand, anything configuration related is in the new mariadb-galera-package

dpkg-deb -f mariadb-server-galera_12.3.2+maria~deb11_amd64.deb Depends
galera-4 (>= 26.4), gawk, iproute2, lsb-base (>= 3.0-10), lsof, mariadb-server (= 1:12.3.2+maria~deb11), rsync, socat, libc6 (>= 2.4), libgcc-s1 (>= 3.0), libstdc++6 (>= 5.2)

the library is still in the galera-4 package and it's a required dependency of the new package.

2. The upgrade tests usually expect packages from mirror == packages from ci.mariadb.org.
   So at the boundary between old-way / new-way we need to handle these scenarios:

• if the previous major/minor (mirror) doesn't have mariadb-galera-package, update_to_include_mariadb_server_galera won't return anything but this isn't a guarantee that current (ci.mariadb.org) doesn't have it. So we need to also run update_to_include_mariadb_server_galera against ci.mariadb.org repo metadata to include the package in the list.
• if the previous major/minor (mirror) has mariadb-galera-package we can assume the current (ci.mariadb.org) has the package also so nothing special to do other than run update_to_include_mariadb_server_galera against the mirror's metadata.