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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
