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