added the missing bracket and removed the illegal . from the name and
replaced it with a _
This issue has been found after recieving a dnf error during
installation of the mariadb-server-galera package:
>>> Scriptlet output:
>>> Close parenthesis without matching open at line 15 of /var/lib/selinux/targeted/tmp/modules/200/mariadb-server-galera/cil
>>> libsemanage.semanage_load_files: Error while reading from file /var/lib/selinux/targeted/tmp/modules/200/mariadb-server-galera/cil. (No such file or directory).
>>> semodule: Failed!
and the subsequent call of `semodule -lfull | grep galera`
prints nothing and returns 1
The expected output for the installation is to go through normally
without the above mentioned error
And the expected output for `semodule -lfull | grep galera` is:
200 mariadb-server-galera cil
and the command returning 0
The 'mariadb-libs' sub-package contains the MariaDB client library.
However we don't build or use the 'mariadb-libs' sub-package anymore, since
the client library is shipped by the 'mariadb-connector-c' package instead.
This change was done between MariaDB 10.1 and 10.2, which is more than 7 years ago.
The right way would be to set this Obsolete inside the 'mariadb-connector-c'
package instead, but since it's such an acient artifact, I'll just drop it entirely.
This issue was found by RPMlint:
| mariadb11.8-common.noarch: W: obsolete-not-provided mariadb11.8-libs
rpmdeplint error:
mariadb-rocksdb-engine-3:10.11.13-8.fc43.x86_64 provides /usr/bin/sst_dump
which is also provided by rocksdb-tools-10.1.3-1.fc43.x86_64
- why the version of the bundled rocksdb provided by the mariadb-rocksdb-engine
subpackage is not specified inside the spec file and the info about where the
rough version of rocksdb can be found.
This file is already packed in 'mariadb-server-galera'.
Removing this file from the '-common' sub-package makes it identical both with
and without galera, wihch is necessary fixup for the previous commit, to keep
the '-common' sub-package 'noarch'
from the 'mariadb-server' to the 'mariadb-server-galera' sub-package,
as it is only used with the galera cluster and therefore it fits into
the '-server-galera' subpackage more.
This also means that the mariadb-server-galera subpackage can no longer be 'noarch'
as this .so file is located in the '%{_libdir}/mariadb/plugin', which is
an arch-specific directory.
More info about the wsrep_info plugin file:
https://mariadb.com/kb/en/wsrep_info-plugin/
the mariadb-server-galera subpackage is owned by the subpackage.
I did this for the other selinux policy as well to achieve the same with
it as well.
Also changed the occurences of "targeted" to %selinuxtype to make
further administration of the package easier and to make the spec file
more readable.
Also removed the no longer needed BuildRequires of selinux-policy-devel
for the mariadb-server-galera subpackage as no policy is being compiled
as we changed tot he cil format of the policy.
But I needed to add the BuildRequires and Requires of
selinux-policy-targeted for the installation of the policy.
as it removes the need to compile the selinux rules, thus getting rid of
the ``` [!]: Uses parallel make %{?_smp_mflags} macro.````
warning. This change was created as a part of the fixing of the problems
with the rebase to 11.8 which are documented here:
https://bugzilla.redhat.com/show_bug.cgi?id=2368742
Until now, the plugin build only worked when the S3 plugin was build,
since the S2 plugin also requires the 'curl-devel', so it helped to
satisfy this build requirement in the buildroot.
- we were missing the CMake control variable
- I also discovered that the build of the gssapi client plugin -
which we remove, since it is shipped as a part of the
'mariadb-connector-c' package in Fedora,
is somehow also controlled bz the build of the hashicorp plugin.
Need further examination.
of the '-shpinx-engine' sub-package as the 'libsphinxclient' library is
already required by the 'libsphinxclient-devel' 'BuildRequires' of the same
subpackage, therefore it will be provided inside the buildroot even
without the explicit 'BuildRequires'
This binary provides a client interface using the embedded library
instead of the main server.
Also started packing the symlink to the binary called 'mysql_embedded'
and their man pages.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info about the binary here:
https://mariadb.com/kb/en/mariadb-embedded/
for testing from the '-server' sub-package to the '-test' sub-package
Also added the '%{_libdir}/%{majorname}/plugin' directory to the
%files section of the '-test' sub-package to ensure that the directory
does not become unowned if only the '-test' sub-package is installed
without the '-server' subpackage.
We don't need the excludes anymore aince we stopped using glob for the
plugin directory.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
sub-package to the main package as it only seems to be used by the
'msql2mysql' utility which is inside the main package,
therefore the replace util fits there better as well as a client util.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info about the util here:
https://mariadb.com/kb/en/replace-utility/
from the '-server-utils' to the '-client-utils' sub-package, as it
connects to the database server using a client interface.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More about the util here:
https://mariadb.com/kb/en/mariadb-dumpslow/
from the '-server-utils' to the '-client-utils' sub-package, as it
connects to the database server using a client interface.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info on the util:
https://mariadb.com/kb/en/mariadb-hotcopy/
and 'mysql_setpermission' utils from the '-server-utils' to the
'-client-utils' sub-package, as it connects to the database server
using a client interface.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info about the util here:
https://mariadb.com/kb/en/mariadb-setpermission/
and 'mysql_convert_table_format' utils form the '-server-utils' sub-package
into the '-client-utils' sub-package because they are written to communicate
with the server part of the package through a client interface.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info on the util:
https://mariadb.com/kb/en/mariadb-convert-table-format/
from the '-server' sub-package into the '-client' sub-package.
It reads data from the client config and it is a client utility.
More info on the utility here:
https://mariadb.com/kb/en/my_print_defaults/
from the '-server' sub-package into the '-client' sub-package,
since it is a utility used by the client part of the package
to set the timezoneinfo of the client.
This change was inspired by the way the Fedora 41 and RHEL 9
RPMs provided by the MariaDB upstream are packaged.
More info about the utility:
https://mariadb.com/kb/en/mariadb-tzinfo-to-sql/
We don't actually need the patch to stop the files from packing.
We called the 'install' deliberately before that patch, but the upstream CMake
do not pack them by default.
It still builds them though, so I still proposed this patch upstream with default
to 'OFF' so we can save a bit of wasted computational time.
https://github.com/MariaDB/server/pull/4078
so that the user can access it using the 'mysql.service' and 'mysqld.service'
names even before the first call of 'systemctl enable mariadb.service' which
creates the symlinks.
This has been consulted with the systemd team and approved by them.
The update is acutally a mirror of what MariaDB upstream is doing in their RPMs.
as there seems to be no good place for them inside
the packages as they are no longer provided by upstream.
The INFO_SRC file contains the information about the source the build
was created from and the INFO_BIN file contains the architecture and
cmake flags the build was created with.
These files have been moved around in the history of this package and
there were many opinions on where the files should be provided and
whether they should be provided at all.
e.g. providing the files inside _libidr as we did so far:
https://bugs.mysql.com/bug.php?id=61425
and not providing the files at all:
https://jira.mariadb.org/browse/MDEV-6526
As a result of this the tests located inside the main testsuite that
check for these files (file_contents.test) have been updated to no
longer check for these files (as seen in the jira link above).
Before this update we used a patch to update these tests to take into
the consideration the location we moved the files to, which was removed
in the rebase to 10.1.24 as seen here:
https://src.fedoraproject.org/rpms/mariadb10.11/c/789b009
These files could be useful in case someone decides to rebuild the
package themself and needs to debug their rpms against the rpms provided
by us. However Fedora has existing standardized solutions by design to
inspect from what sources and how the package was built, so packaging
these files is redundant.
Nor these files should not be in the server subpackage.
This PARTIALLY REVERTS commit 9f34c64543.
--
My assumption in the original commit was incorrect.
It's true we're creating the `/run/mariadb` directory at the RPM level.
However, the `/run` directory is tmpfs, which means it's non-persistent and gets cleaned after reboot.
The tmpfile.d configuration was making sure that after reboot, the `/run/mariadb` directory is recreated.
But after it has been dropped, at the time of reboot, the `/run/mariadb` dir is removed and not recreated, thus causing this issue.
--
Resolves: rhbz#2364619
I discovered that the second call of "cmake -LAH" further changes the cache.
That was definitelly unintended. Applying "-N" to operate in "cache read-only" mode.
That however broke the build, since the compilation flags are set up during the "cmake" call.
Up until now, the code flow was:
1) %cmake ...
2) <adjusting compilation flags>
3) cmake -LAH
And since the "cmake -LAH" without the "-N" argument changed the cache, it actually applied all the
adjustements in the second step. When switched to "-N" mode, the flags failed to be applied, and the build broke.
What we actually need to do is to:
1) initialize the compilation flags with the distribution default values
2) adjust the compilation flags
3) %cmake ...
3) cmake -N -LAH
This way the compilation flags are correctly applied during the first CMake call,
and the CMake cache remains unchanged during the second CMake call.
--
The '%cmake' macro contains the '%{set_build_flags}' macro at it's beginning
https://src.fedoraproject.org/rpms/cmake/blob/b3bf0e/f/macros.cmake.in#_20
and the '%{set_build_flags}' macro is constructed with the:
CFLAGS="${CFLAGS:-...}
syntax, which translates to "Use the content of the $CFLAGS variable. If empty, use the following default value: '...' ".
So we first need to call the '%{set_build_flags}' macro separately, so we apply the default values. Then we append to them.
And then the '%cmake' macro calls the '%{set_build_flags}' macro that finds the existing values, and uses them, instead of the default ones.
we use a downstream one.
The 'INSTALL_SYSTEMD_SYSUSERSDIR' CMake option is of a type 'string',
so only setting to an empty string makes the statement FALSE in contidions.
The 'tmpfiles.d' functionality requires 'systemd'.
That is inappropriate for container use-cases, where
we can save 15-20 MB by removal for the systemd stack.
In the case of MariaDB, we
1) were NOT using the upstream tpmfiles.d config
2) we were used downstream tmpfiles.d config
2.a) which only contained creation of the PID file dir (/var/run/mariadb)
This can be easily replaced by RPM creating and owning the path.
By closer inspection I found that we do it already, so the current tmpfiles.d config
just do entirely redundant job. I assume this was an overlook when the tmpfiles.d config
was introduced.
This commit:
1) removes the donwstream tmpfiles.d config file
2) sets "INSTALL_SYSTEMD_TMPFILESDIR" CMake option to an empty string
to disable generating the upstream config file
3) Drops the "Requires" to 'systemd' to "Recommends"
so the systemd can be ommited in containers, but is still installed by default
4) Drops the '%{?systemd_requires}' macro, which makes sure the systemd is present
for it's %post, %preun and %postun scriptlets.
This can only happen when someone calls the installation or removal on a system that does not
have systemd, which is highly, highly unlikely nowadays.
And in the cases where it is expected - e.g. containers - the %systemd-{post,preun,postun} marcos
contains a condition that makes sure it's content is only run when the systemd is present,
so the effective functionality remains unchanged.
This will allow to make the server-utils a noarch package and
also this will make container setup easier, when installation
of the DNF weak dependencies are disabled.
