Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended
Mike Hommey <mh@glandium.org> writes:
> 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)
I see that there's further discussion of this, and I didn't want you to
think that I was ignoring it. I think this is something we should look at
once we add information about symbols files to Policy, including what to
do with shlibs files when you have symbols files. There's another bug
open about that at the moment, I think.
I'm going to duck this problem for this particular work, though, since
it's a larger discussion and this particular patch doesn't make things any
worse for this case than it was before.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: