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

Re: Shared library versioning

On Thu, Jul 07, 2005 at 10:13:20AM +0200, Alexis Papadopoulos wrote:
> Hello,

> I'm actually making some .deb packages out of a single source archive. One of
> them should contain a shared library. The upstream author's package's version
> is 5.13 and the soname of his library has been set to 513. After having
> contacted him, he told me that was done because apparently each time the new
> version of the library became uncompatible with the previous ones, the major
> version should be incremented, something that was disturbing because the
> library is often subject to modifications leading to incompatibilities.

> After having searched around on the internet I didn't find any information on
> this, but I read once again the SONAME chapter of the debian library
> packaging manual and didn't see this "method" of versioning mentioned.

> What I understood so far is that when upgrading a shared library the old
> version is left around and only the link libname.so is updated. What happens
> now if I update this shared library without recompiling the software that was
> linked agains the old version ?

The general rules of thumb as I understand them are:

* If the ABI changes in a way that's not backwards-compatible, ie symbols
  change meaning, order or are deleted, you have to increment the sover

* If the ABI changes in a way that's backwards-compatible, ie symbols are added
  to the end of the list only, you should not increment the sover. You _do_
  need to fix the shlibs file in the Debian package, though, since programs
  built against this library are not backwards-compatible.

Failing the first means programs stop working mysteriously.

Failing the second means programs have to be recompiled excessively, as they
will refuse to work with an otherwise usable library becaues the sover changed.

Unless the library is in an incredible state of flux, the sover probably ought
to be the major version you mentioned above.

If it _is_ in such an incredible state of flux, and it's not huge, consider a
static-only version, ala ffmpeg or xlibs-static. (Although I believe policy has
some strong words against this path... it introduces major pain for archs that
aren't i386 and PPC revolving around PIC/nonPIC code.)

If the library's in flux, not staticable, and used only by the related
programs, then maybe bundling it all together in one .deb, and putting the
library somewhere below /usr/lib private to that deb (or that source) might
work. This is how FreeRADIUS stores all its private libraries and modules.

I believe there is work underway to make dh_shlibs a little bit cleverer about
working out when you've gotten the rules wrong... Although I can't see how
that'd work without having the previous version of the library at hand. But for
the moment, care and caution is the motto. ^_^

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.

Attachment: pgpoZa51oZveO.pgp
Description: PGP signature

Reply to: