because port files (namely, patches) are tightly coupled to the server code, we should maintain our own version of the port, where all files (server's and port's) are changed in sync.

We need this already if we want CI with ports.

For example, a patch for wsrep_sst_mariabackup.sh in 10.3-10.5 ports doesn't apply after MDEV-27524.
I've made it work for now by "patching the patch" directly in the buildbot step, but of course it's not sustainable and meaningless.

Otherwise, 10.3+ builds from ports / main MTR tests have been added to buildbot with a few extra tweaks:

• a patch for MDEV-15795 is needed for 10.3-10.4. It's been fixed in 10.5+. Buildbot now adds a one-line version of the patch to ports at runtime, but to continue, we need either to backport the fix to 10.3-10.4, or add it to ports for real, or give up on 10.3-10.4 and only run 10.5+. Otherwise MTR fails almost inevitably with weird errors which are in fact illegal instruction aborts;

• there are no ports for 10.7+. Currently buildbot re-uses 10.6 with a few version replacements, and it works for now, but I'm not sure it will last long;

• for 10.4, mysqltest binary is not installed, so buildbot copies it to /usr/local/bin. Same for replace binary and mysql_client_test on 10.5;

• the build requires galera. Buildbot installs a binary package available in FreeBSD (galera or galera26). It's not strictly necessary as it can apparently build it as a dependency, but it saves time;

• additionally buildbot patches Makefile in the server ports to set DINSTALL_MYSQLTESTDIR=mysql-test. It is not necessary, but it makes the build produce a proper mysql-test/plugin directory, with actual suites in it, which I think is better than faking an empty one.

The buildbot runs FreeBSD 13.0 for all 10.3+ branches and FreeBSD 12.3 for main 10.3+ branches unless we decide otherwise.
The builders are currently in experimental, waiting for MDEV-28224 to be merged up to all versions.

With MDEV-28224 fix in place, 10-20 MTR tests fail for each version, the failures need to be addressed separately, most of them seem technical at the first glance.

MTR failures as of April 13:
10.3
MDEV-28303
MDEV-28304
MDEV-28309
MDEV-23920
MDEV-27727
MDEV-24058
10.4
MDEV-28303
MDEV-27724
MDEV-28309
MDEV-23920
MDEV-27727
MDEV-24058
10.5,10.6,10.7
MDEV-28303
MDEV-27724
MDEV-23920
MDEV-27727

serg First off: lame excuses: Apologies for a delay in responses. Paid work, holidays and a nice bit of viral infections are eating my available time on porting. I wake up mostly on the quarterly security updates :/.

You mean akin to the /debian/* structure? If that is what make the Debian packages that would be swell!

Can we assume that mariadb port files are basically the same in all supported FreeBSD version? Will we need some FreeBSD-version-specific checks in the Makefile or somewhere?

We sure can! And I would be all for it! There's issues with the current build infra where FreeBSD behaves very different from Linux packaging. We'd need to resolve these:

1. FreeBSD builds the "parts" separately. I.e. it should actually build `databases/mariadb-connector-c`, then build `databases/mariadb[0-9]-client` which depends on the correct connector-c port and then build `databases/mariadb[0-9]-server' port which depends on the correct mariadb-client port. If this requires a versioned `mariadb-connector-c` port, I believe it does, this WILL happen. I'm insufficiently skilled in CMake to rip apart these parts to properly make them depend out-of-source to e.g. `/usr/local/lib/`. I believe the Linux distros build the whole thing (libraries/client/server) and then split the resulting files in separate packages: FreeBSD fails on this feature. Many kloc of CMake code make MariaDB not an easy entry to CMake (GUIDE ME!)
2. FreeBSD ports must stay away from bundled software. Any library (e.g. any of the compression libraries lzo, lzma, zstd) must be consumed as a dependency, not built from the MariaDB tarball. The recent releases seem to deal with these dependencies a lot better.
3. VM's will depend on the supported FreeBSD versions and architectures indeed. Currently that would be 12.4 and 13.0. CI would be appreciated.

FWIW. I managed to reduce the number of patches required for MariaDB significantly by ignoring/commenting the server/client specific files in the package. You can clearly see this when you compare the number of patches required at the expense of maintaining "what files are client, which are server?" in the pkg-list.
https://github.com/freebsd/freebsd-ports/tree/main/databases/mysql80-server/files
https://github.com/freebsd/freebsd-ports/tree/main/databases/mariadb105-server/files

I very much hope this doesn't sound like an insurmountable list of requirements to you. I could really do with some help here! In return you can count on me to support you with all the FreeBSD port intricacies.

Cheers, Bernard.

MDEV-11791

1. *-client port uses *-server port. only applies a few patches on top. I think we'll be able to keep *-client very source-code-independent, and only put the *-server port files into the server repo
2. yes, that's not a problem
3. now we have 12.3 and 10.3 as far as I can see. I hope port files won't depend on freebsd version

The https://github.com/freebsd/freebsd-ports/blob/main/databases/mariadb106-server/Makefile will no longer work on MariaDB Server 10.7 or later starting with this merge because there will be no files matching storage/innobase/*.cmake. Before 10.7 and MDEV-12933, there would be some files for detecting various compression libraries.

I had a quick look at the patch- files in https://github.com/freebsd/freebsd-ports/tree/main/databases/mariadb106-server/files and I think that we should simply try to apply them to the MariaDB code base. patch-tpool_CMakeLists.txt seems to miss some condition, so that the addition would only apply to FreeBSD.

spil, how could we best proceed with the patch- files? Would it be possible to submit them as pull requests?

I have added a workaround for the innobase cmake files problem above, just one more time.
But unless we start making some progress in regard to integrating the FreeBSD patches into the code base, next time something diverges I'll start disabling the builder for the diverging versions. It is really one of most meaningless tests that we have in the buildbot: it is meant to test that the tree in question builds with FreeBSD ports, yet we patch the ports at runtime every time it stops building; and for 10.7+ we fake the ports entirely, as they don't exist. So it isn't testing anything.