Re: Downstream .so versioning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux