On Tue, 21 Dec 2010, Tom Lane wrote:
I'm fooling around with trying to update mysql from 5.1.x to
5.5.x.
One of the things that's happened in that transition is that they've
dropped the separate "libmysqlclient_r.so" library --- presumably
everything in regular "libmysqlclient.so" is now thread-safe.
Upstream's idea of maintaining ABI compatibility is to provide
symlinks, libmysqlclient_r.so.16.0.0 -> libmysqlclient.so.16.0.0
etc. I find that that only sort of works --- RPM fails to generate
the --provides entries that it used to. So for example I have
this with the old RPMs:
$ rpm -qp mysql-libs-5.1.52-1.fc13.x86_64.rpm --provides
config(mysql-libs) = 5.1.52-1.fc13
libmysqlclient.so.16()(64bit)
libmysqlclient.so.16(libmysqlclient_16)(64bit)
libmysqlclient_r.so.16()(64bit)
libmysqlclient_r.so.16(libmysqlclient_16)(64bit)
mysql-libs = 5.1.52-1.fc13
mysql-libs(x86-64) = 5.1.52-1.fc13
but the closest I've been able to get with the new ones is
$ rpm -qp mysql-libs-5.5.8-1.fc13.x86_64.rpm --provides
config(mysql-libs) = 5.5.8-1.fc13
libmysqlclient.so.16()(64bit)
libmysqlclient.so.16(libmysqlclient_16)(64bit)
mysql-libs = 5.5.8-1.fc13
mysql-libs(x86-64) = 5.5.8-1.fc13
I thought for a bit that RPM was ignoring symlinks for this purpose, but
even copying instead of symlinking the library didn't get me a second
set of provides items. What drives those decisions?
The file must be recognized as being ELF by libmagic for the ELF soname
dependencies to be generated, so yes the upstream symlink approach wont
work. The other part of the puzzle is that rpm reads the ELF soname, and
if it doesn't exist, basename of the file is used as a provide (to match
the linker behavior). As the mysql libraries apparently do have a soname,
the basename wont be used even if you copy/link to another name.
One possibility is to keep the upstream created symlinks and add the
necessary provides manually in the spec.
- Panu -