Resolves: #2283500
--
Script used for checking the files inside "/usr/share/mariadb*"
| # Find directories that start with 'mariadb' under /usr/share/
| find /usr/share/ -type d -name 'mariadb*' | while read -r dir; do
| # For each directory found, recursively find all files and directories
| find "$dir" -print0 | while IFS= read -r -d '' file; do
| rpm -qf "$file" | grep -i -e "not owned"
| done
| done
Results:
| file /usr/share/mariadb-server is not owned by any package
| file /usr/share/mariadb-server/groonga is not owned by any package
| file /usr/share/mariadb-server/groonga-normalizer-mysql is not owned by any package
| file /usr/share/mariadb/mroonga is not owned by any package
Installation path macros are not allowed in file dependencies.
Starting with F40, these break flatpak builds entirely because
dnf5 only recognizes file deps in /etc, /usr/bin, and /usr/sbin,
not /app/etc. At this point, mariadb-connector-c-config is the
sole provider of my.cnf.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies
These sub-packages (errmsg and common) are only required by the same build
of mariadb. When built with the automatic provides (that adds %{_isa} as well),
these noarch sub-packages cause koji to complain and build to fail with:
BuildError: The following noarch package built differently on different
architectures: mariadb-errmsg-10.11.6-2.fc40.noarch.rpm
rpmdiff output was:
removed PROVIDES mariadb-errmsg(x86-32) = 3:10.11.6-2.fc40
removed PROVIDES mariadb10.11-errmsg(x86-32) = 3:10.11.6-2.fc40
added PROVIDES mariadb-errmsg(x86-64) = 3:10.11.6-2.fc40
added PROVIDES mariadb10.11-errmsg(x86-64) = 3:10.11.6-2.fc40
Explanation for removed notes follow:
| * Enable creation of the log file by logrotate (needed since
| /var/log/ isn't writable by mysql user); and set the same 640
| permissions we normally use.
This is an ancient artefact.
It originates in this commit from 2012 in the 'mysql' package in Fedora:
https://src.fedoraproject.org/rpms/mysql/c/d3bdaa4a?branch=rawhide
That was at the time, when the DB log resided directly in '/var/log/', rather than '/var/log/some-dir-specific-for-the-DB/'.
Since that is no longer the case, the 'create 600 mysql mysql' directive is no longer necessary.
| * Comment out the actual rotation commands, so that user must edit
| the file to enable rotation. This is unfortunate, but the fact
| that the script will probably fail without manual configuration
| (to set a root password) means that we can't really have it turned
| on by default. Fortunately, in most configurations the log file
| is low-volume and so rotation is not critical functionality.
This is no longer true.
Since MariaDB 10.4, which introduced authentication via the UNIX socket,
the 'root' and 'mysql' users can authenticate without login and password.
So we can go back to using 'mysqladmin', or 'mariadb-admin' in this case, to flush logs
| See discussions at RH bugs 799735, 547007
| * Note they are from Fedora 15 / 16
I found no more useful information there. Only information already mentioned in other notes here.
| Update 3/2017
| * it would be big unexpected change for anyone upgrading, if we start shipping it now.
| Maybe it is good candidate for shipping with MariaDB 10.2 ?
Introduction of MariaDB 10.11 is the perfect time.
| * the 'mysqladmin flush logs' doesn´t guarantee, no entries are lost
| during flushing, the operation is not atomic.
| We should not ship it in that state
True, however, no one likely cares about that, in reality, since those logs don't hold any journal-like entries.
Explained here:
https://github.com/MariaDB/server/pull/1556#issuecomment-941886220
| Update 6/2018
| * the SIGHUP causes server to flush all logs. No password admin needed, the only constraint is
| beeing able to send the SIGHUP to the process and read the mysqld pid file, which root can.
| * Submited as PR: https://github.com/MariaDB/server/pull/807
It has been dicussed on the upstream thoroughly and was found far from ideal.
Now, that we can use 'mysqladmin', or 'mariadb-admin' in this case, safely again,
there's no argument to keep using the PID file for flushing logs.
| Update 02/2021
| * Enhance the script as proposed in:
| https://mariadb.com/kb/en/rotating-logs-on-unix-and-linux/
Enhanced again now. Significantly this time, however with a vision that the values will become an OS-independent defaults.
| * Discussion continues in:
| https://jira.mariadb.org/browse/MDEV-16621
Discussion finished.
Better start a new one, if needed.
Revert "Introduce the script for generating sources tarball without a code under a license which was not yet approved for Fedora or RHEL"
This reverts commit 7f8a0e15a6.
Note: MariaDB upstream removed TokuDB SE sources in 10.6.0
https://rpm-software-management.github.io/rpm/manual/spec.html
This code was likely meant to deal %license tag on systems without RPM 4.11,
which could happen when the maintainer wanted to keep close the content
of Fedora SPECfile and RHEL SPECfile at a time.
While in Fedora the RPM 4.11 was present for years before the commit that added this code,
it might not be the case in an old, but still active, RHEL at that time.
The 'mv' command failed after the last commit, beacuse the line
| install -p -m 644 -D selinux/%{pkg_name}-server-galera.pp %{buildroot}%{_datadir}/selinux/packages/targeted/%{pkg_name}-server-galera.pp
which was originally before the cracklib condition, created the target directory tree thanks to the
| install -D
functionality.
Order explanation:
- main parts of the package
- code enhancing the main parts of the package
- debug control
- other plugins and storage engines enabled by default
- other plugins and storage engines enabled only on Fedora
- other plugins and storage engines enabled only on Fedora only on specific architectures
