- Commit https://github.com/mariadb/server/commit/438ed0408c69
introduced `mariadb-common` package and added description. Example in
description is confusing since files referred to are not installed and
not related/owned by the `mariadb-common` package.
- Patch is updating real file/directory description section pointing to
the real examples owned by the package.
- Example:
```
mariadb-client-10.3 install
mariadb-client-core-10.3 install
mariadb-common install
mariadb-server install
mariadb-server-10.3 install
mariadb-server-core-10.3 install
/.
/etc
/etc/mysql
/etc/mysql/mariadb.cnf
/etc/mysql/mariadb.conf.d
/usr
/usr/share
/usr/share/doc
/usr/share/doc/mariadb-common
/usr/share/doc/mariadb-common/changelog.Debian.gz
/usr/share/doc/mariadb-common/copyright
```
Closes PR #1690
Reviewed by: otto@kekalainen.net
This partially reverts commit d7321893d8.
The *.jar files are not being built and all Debian builds are failing
as dh_install stops on missing files. To build them we would need to also
add new Java build dependencies.
In a stable release (10.2->10.5) we shouldn't add new files and certainly
not any new build dependencies, so reverting commit.
Also, the files are located in a different path, and already included
in the mariadb-test-data package:
/usr/share/mysql/mysql-test/plugin/connect/connect/std_data/JavaWrappers.jar
/usr/share/mysql/mysql-test/plugin/connect/connect/std_data/JdbcMariaDB.jar
/usr/share/mysql/mysql-test/plugin/connect/connect/std_data/Mongo2.jar
/usr/share/mysql/mysql-test/plugin/connect/connect/std_data/Mongo3.jar
This change needs to be redesigned and applies only on 10.6 or newer.
MariaDB Server still supports Ubuntu 16.04 "Xenial" until it goes EOL
in April 30, 2021. Thus we need to include a customization for backwards
compatibility.
This change is intended to be applied for all MariaDB versions still
supported, i.e. 10.2 to 10.6.
Checking for the existence of the systemctl command only tells us that
systemd is installed, however it does not tell us if systemd is running.
What we really want to do here is reload systemd if it's installed AND
if it's running. The usual way to check if systemd is running is to
check for the existence of '/run/systemd/system'.
Why would systemd be installed but not running? This is something that
happens when one sets up or upgrade a system in a chroot or container.
For more details refer to the bug report:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983563>
Closes PR #1787
Remove from debian build:
* tokudb
* mroonga
* spider
* ograph
* embedded server
Add ccache to debian build.
Backport 10.3 changes to autobake-deb
that make travis faster.
Merge instructions:
Drop this commit on merge to 10.3
Leave debian/additions/mysqlreport as #!/usr/bin/perl
Acknowledge that `env perl` is a hack, a complete fix
needs to consider which path perl is at and insert into
these scripts.
The usefulness of these scripts is questionable.
On FreeBSD, perl isn't in /usr/bin, its in /usr/local/bin or
elsewhere in the path.
Like storage/{maria/unittest/,}ma_test_* , we use /usr/bin/env to
find perl and run it.
There is a 4 MB hard limit on Travis-CI and build output needs to be less
than that. Silencing the 'make install' step gets rid of a lot of
"Installing.." and "Missing.." and removing all mysql-test files will
make the dh_missing warnings much shorter.
Cherry-picked from 41952c85f1.
There is a 4 MB hard limit on Travis-CI and build output needs to be less
than that. Silencing the 'make install' step gets rid of a lot of
"Installing.." and "Missing.." and removing all mysql-test files will
make the dh_missing warnings much shorter.
Cleanup install_layout to account for multi-arch setup and remove
redundant defines in debian rules.
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>
No functional changes.
Apply this in 10.3 so eventually it is merged to 10.4 and 10.5, which
in turn will have separate wrap-and-sort runs but only for new lines,
and not affecting badly next merges from 10.3 to 10.4 to 10.5.
Also remove a duplicate line that was found thanks to wrap-and-sort.
The Debian build tools add all run-time dependencies automatically. For the
mariadb-rocksdb-plugin the "${misc:Depends}, ${shlibs:Depends}" will become
(based on the build dependencies at build time):
Depends: mariadb-server-10.4 (= 1:10.4.12-1), rocksdb-tools,
libc6 (>= 2.29), liblz4-1 (>= 0.0~r130), libsnappy1v5 (>= 1.1.8),
libstdc++6 (>= 7), libzstd1 (>= 1.3.3), zlib1g (>= 1:1.1.4)
There is no need to manually add run-time build dependencies. Only external
dependencies need to be defined, for example rocksdb-tools could come in
question for mariadb-plugin-rocksdb, and it will be eventually added when
downstream official Debian packaging is merged upstream in a later commit.
Ever since MariaDB 10.0 (and MySQL 5.6.8), the innodb_log_file_size
and innodb_log_files_in_group can be changed between server restarts,
and the redo log files will be resized on server startup if needed.
