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
