[Fedora-packaging] Downstream .so versioning

[Honza Horak]

On 01/15/2014 04:16 PM, Jan Staněk wrote:
> What should one do if the SW he is trying to package produce only
> unversioned *.so files? I'm currently trying to package LMDB [1] as
> possible alternative for BerkeleyDB in Fedora, and the hand-written
> makefile produce only liblmdb.so.
>
> I'm trying to persuade the upstream to change it and start to do it
> properly, however if that fails, what can I do with it on my end?

First, I'd say we really should provide versioned soname every-time, if 
the library is considered a usual library that other packages can link 
against. The question is what downstream versioning schema to chose.

(side note: versioned soname doesn't seem to be necessary in case of 
libraries loaded on runtime using dlopen -- usually extensions, where 
library version is usually checked as well during runtime)

Looking around to some other projects (e.g. v8) people usually tend to 
use version of the package to be soname version of the library. However, 
I see some questions raised by that approach:


Problem #1: It can happen that upstream can introduce soname versioning 
at some point (using x.y.z schema that doesn't correspond with project 
version) and it can result in having two libraries with the same soname 
(downstream's based on version and upstream's based on some other 
schema). Nothing very probable but still better to avoid.

Solution: Using schema "0.version" for library soname should work the 
same as when we provide pre-release versions.

Example: Upstream for package abc-1.2.3 provides unversioned library 
libabc.so, so we should provide versioned library libabc.so.0.1.2.3 
downstream.


Problem #2: Upstream usually keeps compatibility on *some* version level 
(sometimes it is major, sometimes minor version), but usually we are 
able to say which versions are expected to be compatible. That is what 
soname should correspond with and not blindly use first number as a soname.

Solution: Use the soname scheme that correspond with upstream's 
compatibility scheme/policy.

Example: Upstream of package abc-1.2.3 keeps compatibility for the minor 
version, so all versions of 1.2.x are compatible, while 1.3.x are 
generally not compatible with 1.2.x. We should then use soname 
libabc.so.0.1.2 (not just libabc.so.0.1).
Result of such a package would be:
* libabc.so.0.1.2.3 as an actual library file
* link libabc.so -> libabc.so.0.1.2.3
* link libabc.so.0.1.2 -> libabc.so.0.1.2.3
* rpmbuild would generate an automatic provide libabc.so.0.1.2()(x86_64)


I believe this should be somehow incorporated into packaging guidelines, 
but before creating a draft, I wanted to consult this publicly, so we 
can choose the best way.

Regards,
Honza