MariaDB package maintenance

Article for the maintainers of the mariadb package. Most information here could be also applied to community-mysql package.

Build matrix

On the beginning of the SPECfile, there is a building matrix of the parts of the mariadb package, which builds can be enabled or disabled.
Respective sub-packages won't be build.

%bcond_without tokudb
%bcond_without mroonga
%bcond_without rocksdb
%bcond_without oqgraph
%{!?_with_cracklib: %{!?_without_cracklib: %bcond_without cracklib}}
%{!?_with_gssapi: %{!?_without_gssapi: %bcond_without gssapi}}
%{!?_with_connect: %{!?_without_sphinx: %bcond_without connect}}
%{!?_with_sphinx: %{!?_without_sphinx: %bcond_without sphinx}}
%bcond_with    clibrary
%bcond_without embedded
%bcond_without devel
%bcond_without client
%bcond_without common
%bcond_without errmsg
%bcond_without bench
%bcond_without test
%bcond_without galera
%bcond_without backup
%bcond_without config
%bcond_with    debug

Maitenance of the full matrix is rather impossible, it would take 2^20 builds to test all combinations.
However some combinations are very useful:

• Full build
• Minimal build (client, common, errmsg, config)
• Debug build

Disabling of certain parts means in practice sending different flags to Cmake, creation of just a part of the packages, and properly handling %files section.

Package layout

In Fedora we try to stay close to the upstream RPMs layout.
In F>=28 the client library is no longer built and some devel files are no longer packed, as they are provided by mariadb-connector-c package, which is supposed to handle the whole client part.

Most of the plugins and stroage engines have their own subpackage.

In order to put Perl dependencies away from mariadb-server, the mariadb-server-utils subpackage is shipped, which contains them.

We try to have mariadb and mysql packages installable and working together - for example mariadb-server and community-mysql (client).
They both also provides "mysql" names for their packages. Which means "dnf install mysql" can resolve to either.

Patches and other files

Please, be verbose when adding new patches. Both in them and in the SPECfile.

We do ship our own unit files and helper scripts.

Most of the patches were offered to respective upstreams and on many of them the work is being done.

CMake

Run in a configured tree (so, after cmake .)

List of options

   cmake -L

list of options and a help text for each, it usually includes the set of allowed values.

   cmake -LH

Options marked as "advanced", that usually means they're internal and should not be set directly.

   cmake -LAH

%check section and the testsuite

Both MariaDB and MySQL carries their own extensive testuites. They contains over 4000 test by now, from which about 3000 are run in Fedora.
MariaDB testsuite is very stable. MySQL testsuite was very unstable, but the MySQL upstream made a great improvement recently. Still it is not the quality of the MariaDB testuite.

The testsuite can be either disabled totally, at the beginning of the SPECfile

    %{!?runselftest:%global runselftest 0}

Or run without treating failed tests as errors, failing build on them

   %global ignore_testsuite_result 0

The testsuite is highly configurable, but the goal is to run as much test as possible. You can always pick specific test, list of tests, or test suites to be run.

export MTR_PARALLEL=1
export MTR_BUILD_THREAD=%{__isa_bits}

# Usefull arguments:
#    --do-test=mysql_client_test_nonblock \
#    --skip-rpl
#    --suite=roles

(
  set -ex

  cd mysql-test
  perl ./mysql-test-run.pl --force --retry=0 --ssl \
    --suite-timeout=720 --testcase-timeout=30 \
    --mysqld=--binlog-format=mixed --force-restart \
    --shutdown-timeout=60 --max-test-fail=0 --big-test \
%if %{ignore_testsuite_result}
    || :
%else
    --skip-test-list=unstable-tests
%endif
)

There are also arch specific files which contains lists of tests, that are know they fail on Fedora from various reasons and won't be fixed anytime soon.

rh-skipped-tests-arm.list
rh-skipped-tests-base.list
rh-skipped-tests-ppc.list
rh-skipped-tests-s390.list

Failure of bigger amount of tests (dozens) should always go though maintainer attention!

Building and testing

Full KOJI builds are significant load for the Fedora build system.
The compilation can take up to 2 hours and the testsuite can take from a few hours to dozens of hours - depends on arch and available hardware.

Most of the work is recomended to be done in mock. Scratch builds are recomended to do on x86_64 arch without the testsuite.
COPR has simmilar limitations as KOJI - thoughtfulness to other users is needed.
The KOSCHEI is great source of information for mostly rawhide issues originating in Cmake, GCC or rpm-redhat-config updates.
BODHI is a great source of many different RPMLint checks. They should be taken in mind and there should always be an initiative to decrease number of the errors and warnings found.

Some prepared CI tests can be found on the GitHub. They should be run for every update.

Upstream contact

The MariaDB upstream is very helful.

The main contact channel should be git pull requests https://github.com/MariaDB and JIRA issues https://jira.mariadb.org/ .
Mailing lists, such as maria-discuss @lists.launchpad.net, and maria-developers @lists.launchpad.net are great to use.
The developers can also be contacted via IRC on freenode on #maria and #maria-dev channels.