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

[Mike Hommey <mh@glandium.org>]

On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote:
> Russ Allbery <rra@debian.org> writes:
> 
> > I read through the shared library sections of Policy a few times last
> > night and can't find anywhere where Policy unambiguously recommends
> > always including a version in SONAME for public libraries.  If you don't
> > have a version, you can't represent the library in the shlibs format, so
> > there's an implicit recommendation, but I think it would be better to
> > make it explicit.

Please note that while not having a version in the SONAME didn't work
well with shlibs, it does work well with symbols file.

Now, I've been wondering for a while if we shouldn't relax our rules on
SONAMEs considering the above, for libraries whose ABI doesn't change in
an incompatible way. Here, I'm obviously thinking about libnspr4 and
libnss3 (and I'm unsure there are more such cases): the libraries never
have incompatible ABI changes, are really intended to be named as such
(i.e. use -lnspr4 and not -lnspr), and are shipped without a SO version
in other distributions.

In other words, in the case of libnspr4 and libnss3, the only tangible
reason to have a SO version and therefore being partly incompatible with
other distros, is to accomodate the shlibs system, that isn't even used
when symbols files are available (with a recent enough dpkg ; iirc,
lenny's dpkg is fine)

Mike