Bug 1501933

> %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