Per https://copr-be.cloud.fedoraproject.org/results/praiskup/mariadb-connector/fedora-rawhide-i386/00630261-bacula/root.log.gz
> %pre devel > rpm -qf /usr/lib64/mysql Calling rpm from rpm is a bit scary :). > if [ $? -eq 1 ]; then > if [ "$(ls -A /usr/lib64/mysql)" ]; then > mv /usr/lib64/mysql /usr/lib64/.mysql_update_tmp > fi > rm -rf /usr/lib64/{mysql*,mariadb*} > fi I'm not really sure what's the purpose of this stuff, could we remove that?
Hi, I already know about this issue and I know it will need a chnage in some way. Purpose: * Several versions of mariadb package in several Fedora version had incorrectly set ownership over the "/usr/lib/mysql" directory. * Several other versions of connector-c tried to install "/usr/lib/mysql" as a symlink to a directory, which broke even more stuff. Solution: * Add scriptlet, which check, if user upgrades from somehow-broken mariadb or mariadb-connector-c version and fix the issues, that block the clean upgrade. (Please note, that without such a scriplet, users would stick to broken verison and wouldn't be able to update to new verison) Problems: * Calling RPM from RPM: Well, should I rather 'rm -rf' in libdir without any check? :) * There should be more checks and work added, Like checking the "mariadb" directory too * Calling "rm -rf" inside libdir is unpleasant thing to do at all. However I must find a way to fix broken mariadbs and connectors idstributed amongst users.
Solution: Move mariadb library from "/usr/lib64/mysql" or "/usr/lib64/mariadb" directly to "/usr/lib64". Scriptlet now only checks, if those locations are symlinks. In such a case, it removes them.
A bit more comments (some unrelated), re-opening to not fill another bug: 11 %if 0%{fedora} >= 28 12 # RPM does not expand "less" correctly 13 %else 14 # mariadb-connector-c is a part of mariadb. *Every* file is meant to conflict. 15 # From F28 the client library part was removed from mariadb and tis package is required instead. 16 # On F<28 is the package present from both historical and compatibility reasons. 17 Conflicts: mariadb-libs mariadb-devel 18 %endif What's the point in having this conditional? Not only that it Conflicts, I think you should also unconditionally obsolete them (to actually enforce that those packages are uninstalled automatically for any upgrade path). Shouldn't actually devel obsolete devel, and libs obsolete mariadb-libs? 28 %if 0%{?__isa_bits} == 64 29 Provides: libmysqlclient.so.18()(64bit) 30 Provides: libmysqlclient.so.18(libmysqlclient_16)(64bit) 31 Provides: libmysqlclient.so.18(libmysqlclient_18)(64bit) 32 %else 33 Provides: libmysqlclient.so.18 34 Provides: libmysqlclient.so.18(libmysqlclient_16) 35 Provides: libmysqlclient.so.18(libmysqlclient_18) 36 %endif # isa_bits This seems weird. What's the point to provide sonames, if we do not even provide compatibility symlinks? Dependency resolvers are just "cheated". 99 # Remove static linked libraries and symlinks to them 100 rm %{buildroot}%{_libdir}/libmariadbclient.a 101 rm %{buildroot}%{_libdir}/libmysqlclient.a 102 rm %{buildroot}%{_libdir}/libmysqlclient_r.a As a good security measure, do `find %buildroot -name '*.a' -delete.
107 %pre devel 108 if [ -h %{_libdir}/mariadb ]; then 109 unlink %{_libdir}/mariadb 110 fi 111 if [ -h %{_libdir}/mysql ]; then 112 unlink %{_libdir}/mysql 113 fi Per [1], it seems like we should use %pretrans instead. I would very much appreciate if there was citation where the idea comes from (proving that we don't do ugly hacks, but just implementing known work-around). [1] https://fedoraproject.org/wiki/Packaging:Directory_Replacement