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

[Wan-Teh Chang]

On Wed, Aug 27, 2008 at 11:55 AM, Howard Chu <hyc at symas.com> wrote:
>
> And library versioning tells you at a glance what version of a library you
> currently have installed. It's the norm on all POSIX systems that use
> SVR4-derived shared libraries (which is pretty much all of them, these days).
> Otherwise you have to use specialized tools to inspect the library and
> discover it's actual version.

This is true, but libnss3.so tells me it's NSS 3.x, while
libc.so.6 doesn't tell me it's glibc 2.  You actually need
to know the history of libc on Linux to know what "6"
means.

This is why I think the libnss3.so soname (as opposed to
libnss.so.3) is just a cosmetic issue.  Of course, I realize
that I have seen libnss3.so so long that I could miss
something obvious, such as people expect to see a
number after .so in a soname.

> The current approach you've described for NSS is just a subset of the standard
> shared library features. It seems pretty strange to push a library into a
> Standards Base when its naming is so obviously non-standard, and there's no
> technical reason why it couldn't just use a standard-conformant name.

I'm very interested in knowing what the "standard" soname
naming convention is in LSB.  The examples that Mats
gave showed that there are at least two soname naming
convensions.

Wan-Teh Chang