Two reasons:
1) This license is included due to the Perl module 'Expect'. However I wasn't able to actually
locate it's sources in the MySQL source tarball. I believe it's a remnant of a code that was
removed in the past.
I've asked the MySQL upstream to verify my claim and either disprove it or fix the LICENSE
file in wihch they mention it.
For this reason I believe the 'GPL-1.0-or-later' also does not apply, so I'm removing it too.
I'll put the 'GPL-1.0-or-later' should upstream disprove my findings.
2) As per clarification on the Fedora License mailing list:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/message/LBAZXYBAA4YHJ2GEWEP5S7QXVOB76MUR/
"
If your package is licensed under a known choice of two licenses and
one is a "good" license and one is a "bad" license, then the License:
field must reflect the "good" license only. This is highly uncommon in
Fedora packages apart from the case of Perl modules dual licensed
under the GPL and the Artistic License 1.0. In that case you must pick
the appropriate identifier for the GPL side (which in Perl modules
will typically map to SPDX "GPL-1.0-or-later"). You are encouraged to
include a comment memorializing this, for example:
\# Upstream project is dual licensed GPL | Artistic 1.0
"
After discussion with change owner, I've prepared the correct solution.
There is a difference between Fedora and CentOS Stream 10 / RHEL 10:
- in CentOS Stream 10 / RHEL 10, the change is self-contained by the
'openssl-devel' package itself, which now defines OPENSSL_NO_ENGINE
in the headers so new application builds don't use engine at all
- in Fedora, the headers containing the OPENSSL_NO_ENGINE definition
are put into a separate sub-package 'openssl-devel-engine', instead
of being put into the 'openssl-devel'
mysql-c99.patch
- directory "plugin/innodb_memcached" no longer exists
boost-1.76.0-fix_multiprecision_issue_419-ppc64le.patch
- upstreamed
ExcludeArch: %{ix86}
- MySQL 8.4 is not supported on 32-bit architectures
%ifnarch aarch64 s390x
BuildRequires: libquadmath-devel
%endif
- sub-package of gcc
- Only available on some architectures
%{_bindir}/mysql_upgrade
- was deprecated in 8.0
- now no longer available
%global runselftest 0
- disable testsuite during development time,
takes ages to complete on s390x and produces random failures on ppc64le
- I've checked that the result is sane
- testsuite enabled
- testcase checking disabled, as it produces huge amount of errors before each test even begin
these errors seems to be fully non-deterministic (random)
These packages are either not needed, or are brought in anyway by their *-devel sub-packgages.
It is possible to check whether the MySQL miss something by searching through the CMake checks, for "EXECUTABLE-NOTFOUND" keyword.
Some are expected to be missing. e.g. Git.
We don't want the MySQL to try to additional sources from web from git during compilation (not like it can anyway, but without the git, CMake won't even try)
List of currently not found executables, for future reference:
GIT_EXECUTABLE:FILEPATH=GIT_EXECUTABLE-NOTFOUND
DOXYGEN_EXECUTABLE:FILEPATH=DOXYGEN_EXECUTABLE-NOTFOUND
DOXYGEN_DOT_EXECUTABLE:FILEPATH=DOXYGEN_DOT_EXECUTABLE-NOTFOUND
CTAGS_EXECUTABLE:FILEPATH=CTAGS_EXECUTABLE-NOTFOUND
PATCHELF_EXECUTABLE:FILEPATH=PATCHELF_EXECUTABLE-NOTFOUND
When you try to use system version of the library, following error emerges:
| -- Performing Test HAVE_RAPIDJSON_WITH_STD_REGEX
| -- Performing Test HAVE_RAPIDJSON_WITH_STD_REGEX - Failed
| CMake Error at cmake/rapidjson.cmake:114 (MESSAGE):
| System rapidjson lacks some fixes required for support of regular
| expressions. See extra/RAPIDJSON-README for details.
| Call Stack (most recent call first):
| CMakeLists.txt:1952 (MYSQL_CHECK_RAPIDJSON)
| -- Configuring incomplete, errors occurred!
I specifically chose not to specify version in the bundled(rapidjson),
to avoid confusion that it's the same version as of the system variant of the library from package 'rapidjson'
Both are set to 'bundled' by default !
We really want to avoid bundling zlib.
On top of that, there is currently a problem with the bundled zlib, which results in a linker error during compilation.
We want to un-bundle rapidjson too, but:
| -- Performing Test HAVE_RAPIDJSON_WITH_STD_REGEX
| -- Performing Test HAVE_RAPIDJSON_WITH_STD_REGEX - Failed
| CMake Error at cmake/rapidjson.cmake:114 (MESSAGE):
| System rapidjson lacks some fixes required for support of regular
| expressions. See extra/RAPIDJSON-README for details.
| Call Stack (most recent call first):
| CMakeLists.txt:1952 (MYSQL_CHECK_RAPIDJSON)
| -- Configuring incomplete, errors occurred!
needs further investigation.
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
--
Based on commit 45b40b2 in rpms/mariadb10.11 authored by Yaakov Selkowitz on Apr 8 2024
45b40b2e9c
When building the package as alternative (non default) version
for a distro, we should not have provides that are virtual and
without version. Otherwise, packages that depend on these
virtual provides (like build requires of perl-DBD-MySQL),
could install the non-default version by accident.
The sub-package 'mariadb-common' contains XML files with character sets
The sub-package 'mariadb-errmsg' contains 'errmsg.sys' files with error messages for various laguages
