[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Fri, Jul 09, 2010 at 05:09:05PM +0200, Mike Hommey wrote:
> 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.

FSVO "well" that encompasses "fails to prevent uninformed maintainers from
shipping shared libraries that lack any sensible ABI management and breaking
upgrades in future releases".  (Not referring to your packages here; I mean
that this will be a problem in the archive in general.)

> 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)

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.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: