Introduction to packaging
MariaDB aims to be universally available to everybody on all possible platforms and we welcome contributions related to the effort. MariaDB is already available for many operating systems (Windows, Mac, Linux..) and many variants of them (Fedora/Red Hat, Debian/Ubuntu, SUSE..) and MariaDB runs on all major architectures (Intel, Power..) but there are still platforms out there that don’t have MariaDB available or where the MariaDB user experience is not perfect yet. There are also completely new packaging formats (Snap, Flatpak..) and related systems (Docker, Rkt, Juju) that don’t have fully developed and tested MariaDB setups available.
We encourage everybody with expertise in a particular system to reach out to us and contribute by making MariaDB work perfectly on their platforms of choice.
Packaging flow at upstream MariaDB git repository
The MariaDB Server and Connectors are developed publicly at Github.com/MariaDB. The upstream source repository for the MariaDB Server includes files related to .deb packaging in the directory debian/ while RPM related files and some others can be found in the directory support-files/.
When a new version of MariaDB is released, the official release is published as a tarball at downloads.mariadb.org. Each release is also built into various packages and made available from the same place.
In fact, every single commit on the main trees are built into packages by our continuous integration system Buildbot. This makes it possible for MariaDB developers to spot early on any changes that break packaging or causes install/upgrade issues. In the Buildbot grid view one can see which packages are built and tested automatically.
Everybody contributing to packaging is encouraged to do it as pull requests and patches directly upstream, so that their work is tested by the official CI system of MariaDB and reviewed and verified by as many MariaDB developers and users as possible.
Also, having the packaging stuff done directly in the upstream source tree makes developers aware of it and makes it less likely, that a future release of MariaDB would break packaging or otherwise complicate it downstream.
Packaging in downstream repository
In some cases, packaging can only be done downstream. For example, the MariaDB in official Debian and Ubuntu repositories does not use the files in debian/ as they exist in the upstream release, but they have their own Debian hosted git repository where the official Debian/Ubuntu packaging happens at salsa.debian.org.
This is due to the general Debian Quality Assurance workflow, where Debian specific processes and Debian specific bugs filed at bugs.debian.org need to be addressed in a quick cycle by fixing the issues in Debian and making new Debian revisions of the same upstream MariaDB release (e.g. 10.3.7-1, 10.3.7-2..). The Debian Policy is notorious for having a lot of strict requirements (if printed, it is 150 pages long), and the version in Debian needs to strictly adhere to it, while the upstream packaging can be a bit more lax and target slightly different needs, so it is valid for them to differ. In the long run however even packaging done downstream should be upstreamed to enjoy be future proof and enjoy the benefits of upstream developer attention as explained in the previous chapter above.
The Debian repository contains its own README.Maintainer and README.Contributor explaining the Debian specific processes.
How to make packaging changes
If one makes packaging changes in some downstream system, then one should follow the guidelines of that system.
Below are tips on how to make good packaging changes in upstream MariaDB sources.
Deb-packages
All the files related to .deb-packaging (for Debian, Ubuntu, Mint etc) are inside the debian/ directory. The build is done by launching the autobake-deb.sh script. This script is specific for MariaDB and it has been designed so, that it can build the .deb packages for all of the Debian variants and releases MariaDB targets. For example the rules and control files in debian/ are made to target the latest Debian and Ubuntu releases and thus contain the things that are most up-to-date. The autobake-deb.sh file then sniffs the environment where it is run and if some things in the control or rules file are not supported in that environment, it is downgraded on the fly. For example if cracklib version 2.0 or newer is not available, stanzas related to it are automatically removed from the control and rules file before starting the .deb building process as we know it would otherwise fail.
To run autobake-deb.sh you need to have a Debian/Ubuntu-based system, or alternatively use Docker or similar to launch the script in.
Once you have verified your changes locally, you can use a free Launchpad.net account to build it on multiple platforms and Ubuntu release easily, and publish the resulting packages in a personal package archive (PPA) for easy repository based testing. For details see the MariaDB Knowledge Base article Uploading Package to PPA (note this example uses downstream salsa.debian.org version of MariaDB sources, not the upstream git repository).
RPM packages
The upstream MariaDB repository has moved away from defining .spec files manually, and instead relies on the CMake feature called CPack to automatically generate the .rpm files. The definition can be found in cmake/cpack_rpm.cmake.