On Thu, Jul 08, 2010 at 10:10:51AM -0700, Russ Allbery wrote: > Russ Allbery <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
