The package libmariadbclient18 contains the dialog.so plugin, which also
the new libmariadb3 ships. As they both use the exact same path the latter
must be marked as a with Breaks and Replaces relations ship.
Note: This fix is conservative hack for stable releases 10.2 and 10.3.
In 10.4, the development release at the time, we will clean up how the
libmariadb3 packaging and it's -compat packages are done to match that
what is done in downstream Debian official.
The package libmariadbclient18 contains the dialog.so plugin, which also
the new libmariadb3 ships. As they both use the exact same path the latter
must be marked as a with Breaks and Replaces relations ship.
Note: This fix is conservative hack for stable releases 10.2 and 10.3.
In 10.4, the development release at the time, we will clean up how the
libmariadb3 packaging and it's -compat packages are done to match that
what is done in downstream Debian official.
If something was built using a build dependency, it will automatically
be a install dependency via ${shlibs:Depends}, so no need to define it
manually.
This also fixes a bug related to a over autobake-deb.sh mangling
the control file architecture field on Trusty and Jessie.
- Update package names that had -10.3 to -10.4
- Update conflicts/breaks/replaces of to include now also 10.3,
just like 10.3 had the same relationship to 10.2
- Remove some old (<< ${source:Version}) not needed anymore as we
are not moving files around inside the 10.4 releases (at least yet).
- Ensure all plugins depend on server or client binaries from the same
release so that they for sure are binary API compatible.
In RPM/DEB packages - always ld-preload jemalloc, instead
of linking ha_tokudb.so with it.
Keep linking in bintars, because they don't install cnf files
in the correct locations.
All packages in group 'essential' are by default installed on all
Debian and Ubuntu systems, and there is no need to mark them as
dependencies for any binary.
We have carried along this patch as a patch inside our sources
since 2012 (commit cfd4fcb0bc).
The validity of this has thus been vetted in production for years
and the review done now did not find otherwise.
A race in dash causes mysqld_safe to occasionally loop infinitely.
Fix by using bash instead.
https://bugs.launchpad.net/ubuntu/+source/mysql-dfsg-5.0/+bug/675185
As this is the last patch, we can also clean away usage of dpatch.
Add libzstd-dev as a build dependency to the server and libzstd1 as a
runtime dependency for rocksdb. libzstd is practially a mandatory
compression library to ensure adequate performance for RocksDB.
There is no need for MariaDB Backup to be versioned. Other packages are
very unlikely to need to depend on a certain generation of this package.
Also for MariaDB Backup to run, it does not need the server, but client,
and from client only core parts.
It will only build if there is network access, which is a strict no-go
for Linux distributions. Thus the AWS plugin needs to be a custom built
only special plugin that is not built as part of the normal sources.
This fixes the build error in e.g. Launchpad:
Performing download step (git clone) for 'aws_sdk_cpp'
cd "/<<PKGBUILDDIR>>/builddir/plugin/aws_key_management" && /usr/bin/cmake ..
Cloning into 'aws-sdk-cpp'...
fatal: unable to access 'https://github.com/awslabs/aws-sdk-cpp.git/':
Could not resolve host: github.com
RocksDB configure step checks that platform is 64-bit and little endian,
so limit the .deb packages to be built only on those platforms.
List of official Debian platforms at
https://www.debian.org/ports/index.en.html
Using this package any source that expects MySQL Client libraries should
build without changes. Sources that expect MariaDB Connector C should
build using only libmariadb-dev.
Current MariaDB Connector/C does not build quite identically in
this source tree compared to how it build in Debian official.
The remaining differences are tracked in MDEV-14921.
We already ship libmysqlclient18 that replaces any existing package
with the same name and install symlinks that point to out libmariadb.so.
Instead of creating more packages, we add just one more that does the
same and provides both libmysqlclient19 and -20 replacements symlinks.
This is a clean solution, because systems that only use (and are built
against) libmariadb will not need them and if somebody has done a mistake
in the linker parameters, they will spot it and can easily update the
filename to libmariadb.
There is no point in having version suffixes in plugin packages. They
will via their control file anyway depend on the correct server or client
version. Having version suffices has no benefit and it just complicates
upgrades when a new major version name package needs to replace all
possible previous version.
This issue was overlooked when merging commit
844a575946 from 10.2 into 10.3, so it
needs to be manually fixed now.
mariadb-client-core-10.2, mariadb-client-10.2, and
mariadb-server-core-10.2 should not depend on libmariadb3 - they
do not have any binaries dynamically linked with libmariadb3.so
put libmariadbclient18 symlinks into libmariadbclient18.deb package,
not into libmariadb3.deb, because installing/reinstalling
libmariadbclient18.deb must recreate these symlinks.
