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) Paul.Hampson@Anu.edu.au "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