[lsb-discuss] NSS: soname problems and compatibility issues
rrelyea at redhat.com
Wed Aug 27 10:48:31 PDT 2008
Robert Relyea wrote:
> Jeff Licquia wrote:
>> It's been discussed in IRC, but probably should be discussed a little
>> more formally.
>> The proposed NSS spec uses libnss3.so and libssl3.so as the library
>> filenames. But some poking around by a few people revealed that not
>> all distros provided this file.
>> (Additionally, there was a claim on a mailing list that some sonames
>> were changed because of incompatibility issues. But we seem to have
>> lost that reference.)
> There shouldn't be any compatibility issues. Any that arise are p1
> bugs for NSS upstream. We specifically design new versions to slide in
> under old versions so older apps can always user a newer version of NSS.
I should add that one concern debian had was to make sure applications
which were compiled with newer versions of NSS would not have
compatibility problems when installed on systems with older versions of
NSS uses the built in linux SO versioning scheme for this.
There was once a case we (Red Hat) ran into with the browser. A browser
was rebuilt using a newer version of NSS and installed. That browser did
not work on a system with an older copy of NSS. This was caused by 2 things:
1) The browser linked with a static NSS library to do crmf (mozilla
products are the only products I know of that uses this static library).
2) That static library was updated to use a new API exposed in the new
version of NSS.
3) The mozilla package build (at least the RH rpm) was stripping out the
Linux library versioning information that tells the package what version
of the library to use.
NSS uses .def files to control exports of symbols. Each symbol is tagged
with the release of NSS that it was first exported. This is to prevent
the compatibility issue above, however the application in question
stripped that information. The correct fix is not to strip that
information (which is implemented in the RH systems now).
I don't know if debian ran into a similar issue since no one reported
any compatibility issues to the NSS team.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080827/694eaa63/attachment.bin
More information about the lsb-discuss