[Mageia-dev] mariadb

Sat Dec 17 17:10:29 CET 2011

Op zaterdag 17 december 2011 14:23:54 schreef Funda Wang:
+> 2011/12/17 Maarten Vanraes <alien at rmail.be>:
+> > ah, didn't see that one... i've put the mklibnames in variables and
+> > resubmitted.
+> > 
+> > perhaps this can be documented somewhere(.spec file policy), or even
+> > better, fixed?
+> 
+> %mklibname takes a lot of parameters, so:
+> 
+>    Requires: %mklibname mysql %{major} = %{version}-%{release}
+> 
+> will let %mklibname think its parameters are:
+> %1: mysql
+> %2: %{major}
+> %3: =
+> %4: %{version}-%{release}
+> 
+> After parsing, %mklibname only recognize the first three paramerters,
+> and put an underscore between %2 and %3. so it becomes:
+> 
+> %{_lib}mysql%{major}_=
+> 
+> And, %4(%{version}-%{release}) will be throw away.
+
+right, i figured it out, after i saw it. thanks for the lengthy explanation. 
+Speaking with Anssi about this, he mentions that
+
+%{mklibname mysql %{major}} = %{version}-%{release}
+
+would have also solved the issue.
+
+> > PS: I provided the exact provides as mysql, just to be sure that there is
+> > no mageia (or otherwise 3rd party package) could be having troubles
+> > finding the correct packages.
+> 
+> As mariadb is a binary replacement for mysql, why not just named the
+> libs as %{_lib}mysql18 and %{_lib}mysqld18, which is more accurate
+> than %{_lib}mariadb18. Almost all the packages are using binary
+> dependencies (libmysqlclient.so.18) rather than rpm name dependencies,
+> which is more nature than package name, and more reliable.
+
+i understand, however the %mklibname macro is actually meant for this, and 
+will not change.
+
+furthermore, speaking with Anssi about this, 
+
+> Personally, I don't think libmysqld18 (now it is named
+> libmariadb-embedded18) should have any relationship with libmysqld0.
+> They have different libmajor, which means all the packages depending
+> on libmysqld0 should be recompiled. So basically, they are different
+> libs actually. Adding symbolic link won't provide any help, either.
+
+in respect to the embedded libraries, it's not actually,
+
+their upstream version was more or less copied from mysql and the developer 
+who implemented the cmake change in 5.5 branch for mysql, is the same person 
+who's now maintaining that 5.5 cmake branch.
+
+I mentioned that this library should be versioned, and that it's not at this 
+time, he agreed, and said that since it's ABI compatible with mysqlclient, 
+that he should not use 0 major, but the 18 major (same as mysqlclient)
+
+the code is still 100% exactly the same, it just went from unversioned in 
+upstream to versioned.
+
+since we had versioned manually mysqld to major 0, i provided the 
+compatibility symlinks for it.
+