The patch was originally a copy of an upstream commit fixing this issue
Now the commit is a part of the server codebase
https://jira.mariadb.org/browse/MDEV-18737ddce859076
I stopped applying the patch with 10.5.0 release
Upstream issue:
https://jira.mariadb.org/browse/MDEV-19755
Upstream commit:
5cc2096f93 (diff-8576e5effae0770fc984e35e6749c43a8946489a1b478ce54facb3b9086622bf)
Scripts that rely on a specific driver won't work with differently named driver
Following scripts are affected:
mysql_convert_table_format.sh
mysql_setpermission.sh
mysqlhotcopy.sh
mytop.sh
as well as several tests for various components
So changing the required package to match the needs of the scripts
Testing:
Following command:
mysql_setpermission --user=root --host=127.0.0.1 --port=3306
Would fail with:
install_driver(MariaDB) failed: Can't locate DBD/MariaDB.pm in @INC (you may need to install the DBD::MariaDB module)
Related: #1903659
RPMDiff issue says:
File opt/rh/rh-mariadb105/root/usr/share/mysql-test/var is a dangling symlink (to /dev/shm/var_64_BuRk) on x86_64
In the CMake "CONFIGURE_FILE(<input> <output>)" command, the <input> path is treated relative to SOURCE dir, however the <output> patch is relative to BUILD dir.
Since the file has been copied to a wrong location, instead in-place updated as originally intended, the file that was later installed was the original unchanged file.
Resolves: #1873999, #1874446
Fix mariadb-pcdir.patch hunk
Since we do CMake out-of-source builds, and the SOURCE and BUILD directiories differ, the bug that was present in the patch started to cause a issues.
In the CMake "CONFIGURE_FILE(<input> <output>)" command, the <input> path is treated relative to SOURCE dir, however the <output> patch is relative to BUILD dir.
Since the file has been copied to a wrong location, instead in-place updated as originally intended, the file that was later installed was the original unchanged file.
Resolves: #1873999, #1874446
Force the CMake change regarding the in-source builds also to F31 and F32
Use CMake macros instead of cmake & make direct commands
%%cmake macro covers the %%{set_build_flags}, so they are not needed
Other changes to compile flags must be specified *after* the %%cmake macro
When rebuilding mariadb on EL7, I noticed that tokudb, mroonga, and
rocksdb were enabled, despite what this conditional appears to do.
After some experimentation, I can see that %ifarch does not support
appending another conditional with &&. To achieve the desired logic,
the statement must be separate conditionals.
Michal Schorm
Zbigniew Jędrzejewski-Szmek
Lukas Javorsky
Honza Horak
Fedora Release Engineering
Tom Stellard
Carl George
Jeff Law