Re: Question about shared libraries
Hi Shane,
On Wed, 21 Mar 2001, Shane Wegner wrote:
> I have packaged shared libraries in the past but am looking
> for some help with this particular one. I am packaging
> version 1.0.0 of dotconf and rather than naming it
> libdotconf.so.1 as was done for 0.x (libdotconf.so.0) it's
> named libdotconf-1.0.so.0. Now, I was under the impression
> that one named a library libfoo.so.x and incremented x
> whenever there was an API change making it binary
> incompatable with the previous version. How would I
> package something where the major version is actually
> before the .so extention? How should the package name
> change as the API changes? Can I just modify the source to
> call it libdotconf.so.1 and call my package libdotconf1 or
> is that not ideal?
This is unfortunately not a unique situation. Other libraries are maintained
upstream by people who don't understand proper library versioning either (and
by 'proper', I mean "the tried and true method that's been used on Unix for
years and is the known standard"). Case in point is Imlib, which recently
made a 2.0 release... and which ships libraries with the soname
'libImlib2.so.0'.
The problem with trying to correct the library names in the package is that
your packages aren't binary-compatible with third-party software precompiled
for this version of the library; libfoo.so.1 will not satisfy the dependencies
on libfoo-1.0.so.0, no matter how you push on the square peg. Likewise it's
not a good solution to call the package 'libfoo1', because the package name
should indicate the contents. libfoo1 -> libfoo.so.1. If you call the package
libfoo1 and it contains libfoo1.so.0, what happens if the next release is
libfoo1.so.1? The least-bad option that seems to hold forth is to name the
package 'libfoo10' (perhaps with a delimiter between the 1 and the 0?)... and
then petition the upstream to un-break their library names...
HTH,
Steve Langasek
postmodern programmer
Reply to: