What are the ELF shared lib symbol versioning best practices?

Christian Kastner linux at kvr.at
Tue Oct 21 19:58:42 UTC 2014


On 2014-10-21 18:11, Daniel P. Berrange wrote:
> On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote:
>> I assumed that adding them to KEYUTILS_1.4 would be okay because nothing
>> would've tried to use them previously because they didn't exist in any
>> version.
> 
> One thing to bear in mind with symbol versioning is that it also interacts
> with RPM versioning. ie, if an application links to a symbol foo at MYLIB_X.Y
> then the RPM will automatically get a "Requires: mylib.so(MYLIB_X.Y)"
> added to it. 
> 
> This ensures that when you install the application, it pulls in a version
> of the library that is new enough to have all the symbols the application
> needs.
> 
> Note that RPM only depends on the version, not the full symbol name. So
> by adding new symbols to the existing KEYUTILS_1.4 version section, no new
> RPM dependancies will be introduced. So an RPM install of an application
> that uses the new symbols, will still be (mistakenly) satisfied by the
> an old version of the library that lacks the symbols.

Within Debian, library source packages can make use of a special
versioning system which is used by other packages to calculate dependencies.

In this versioning system, every upstream symbol is mapped to the Debian
source package version in which this symbol was introduced into the
archive. For example, for the two symbols discussed above, we have

    [...]
    recursive_key_scan at KEYUTILS_1.4 1.5.2
    recursive_session_key_scan at KEYUTILS_1.4 1.5.2
    [...]

indicating that the two upstream symbols *@KEYUTILS_1.4 where first
introduced into Debian with package version 1.5.2 (apparently upstream
releases 1.5.0 and 1.5.1 were skipped). Consequently, packages built
against libkeyutils1 using those symbols will always depend on a Debian
package version of at least 1.5.2, despite them being marked as 1.4
upstream.

This allows for a much finer control of package dependency calculation
than the default we use. But, of course, this only applies when the
package maintainer actually decides to use this feature.

Just thought this might be something interesting to share.

Regards,
Christian




More information about the devel mailing list