[lsb-discuss] NSS: soname problems and compatibility issues

Wan-Teh Chang wtc at google.com
Wed Aug 27 12:18:39 PDT 2008


On Wed, Aug 27, 2008 at 11:03 AM, Wichmann, Mats D
<mats.d.wichmann at intel.com> wrote:
>
>> NSS uses the built in linux SO versioning scheme for this.
>
> I think the Debian complaint stems from it not really doing this.
> Normally, libraries are provided with a version suffix, and with
> an soname branded into the library.  When you link against a
> library, the soname is added as a requirement for the binary.
> But the soname in, for example, the Fedora 9 copy of libnss3.so
> is just "libnss3.so" - there's none of the usual versioning,
> as in say "libc.so.6" or "libglib-2.0.so.0" (numerical suffix
> serving as the versioning) - it appears to be this that Debian
> decided was their policy to add.

The libnss3.so soname accomplishes the same goal
as libc.so.6.  The "3" in libnss3.so is the major version
number, which is bumped for a new release that is not
backward compatible.

The fact that we put the major number "3" before
".so" rather than after it is unfortunate.  But this is
just a cosmetic problem.  (As an unintended
consequence, it also helps us avoid name conflict
with OpenSSL's libssl.so.)

Since the libnss3.so soname has been used for
eight years, we don't want to change it for cosmetic
reasons.  If the libnss3.so soname causes real
problems, I believe the NSS team is open to
libnss3.so.3 (or libnss3.so.0?), with a libnss3.so
symlink for compatibility.

Wan-Teh


More information about the lsb-discuss mailing list