[lsb-discuss] NSS: soname problems and compatibility issues
hyc at symas.com
Wed Aug 27 11:55:01 PDT 2008
Robert Relyea wrote:
> Wichmann, Mats D wrote:
> Right, that versioning is there because Linux libraries do not normally
> have binary guarantees between various releases. An old library linking
> with a new .so would fail because the new .so has changed the size of
> some important data structure in the API.
> NSS guarantees that won't happen.
>> But this is a different question - this is not library versioning,
>> but symbol versioning. The LSB is using libnss3/libssl3 symbol
>> versioning, and once the proper library is located, it doesn't
>> seem we're having any problems with this part of the draft spec, it
>> appears to be consistently implemented.
> So the point is it doesn't matter which library. If you are an
> application linked against the old library, there is no problem using
> the new library. If you are a new application using the old API, then
> it's still OK to use the old library. If you use new API functions, you
> need to automatically upgrade to the new version of the library. Symbol
> versioning tells you what minimum version of NSS you need to run.
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.
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
More information about the lsb-discuss