What drives RPM Provides for shared libraries?

[Matt McCutchen]

On Tue, 2010-12-21 at 22:10 -0500, 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?

I guess RPM is using the SONAME embedded in the library, which you can
see with "readelf -d".  Assuming that ld.so is happy to satisfy a NEEDED
entry for libmysqlclient_r.so.16 by opening a file with that name and
getting a library with SONAME libmysqlclient.so.16, it seems that rpm
should add the Provides based on the file name.

-- 
Matt