Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended

[Mike Hommey <mh@glandium.org>]

On Sat, Jul 10, 2010 at 12:36:14PM -0700, Steve Langasek wrote:
> It's not that these libraries will never have incompatible ABI changes, it's
> that they encode the ABI information in a non-standard way - the '4' in
> libnspr4 and the '3' in libnss3 do represent the sover, they just do it in a
> manner that's gratuitously incompatible with how all other Unix libraries
> have been versioned since time immemorial.
> 
> If we're going to relax the rules for sonames, I think they should be
> relaxed only to accomodate this particular case of the so version being on
> the lefthand side of the .so extension with no delimiter before it.  I.e.,
> let a shlibs file of 'libnspr 4 libnspr4-0d' do the right thing, but don't
> allow shlibs files with an empty version field.

I'm not totally sure it would be a good idea to modify shlibs to work
that way, and it would somehow feel wrong that a library you link with
-lnspr4 is described as libnspr and not libnspr4 in the shlibs. I just
think the rule should be relaxed, but the implementation should be done
with symbols files.

BTW, are there any other libraries with the same problem, where
compatibility with other distros may be important? (which btw, in the
case of nss and nspr, is even more important since part of these libs
are part of the LSB, which is why the .so symlinks are in the library
package and not the -dev package ; but it would still be better that
binaries built on debian could work on other systems, too, which is not
the case atm)

Cheers,

Mike