[csw-maintainers] Symlinks to shared libraries

[Maciej (Matchek) Blizinski]

On Wed, Nov 25, 2009 at 11:15 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
> Hi Maciej,
>
> Am 25.11.2009 um 11:43 schrieb Maciej (Matchek) Blizinski:
>>
>> I just got a review of my NSPR build from a NSPR/NSS developer,
>> Wan-Teh Chang.  One of the comments was to stop creating a symlink to
>> a shared library.  By default, nspr creates bare *.so files.  My build
>> script renamed them to *.so.$(MINOR_VERSION) and created symlinks from
>> *.so to *.so.$(MINOR_VERSION).
>>
>>> ls -l /opt/csw/lib/nspr/libnspr4.so*
>>
>> lrwxrwxrwx   1 root     other         13 Nov 23 23:46
>> /opt/csw/lib/nspr/libnspr4.so -> libnspr4.so.8
>> -rwxr-xr-x   1 root     bin       324344 Nov 23 23:02
>> /opt/csw/lib/nspr/libnspr4.so.8
>>
>> Do we have any policy which requires creating symlinks?  I'm afraid
>> that shipping bare unversioned libraries is going to create problems
>> during updates.
>
> I don't think that we have an official "policy" on this as most libraries
> are well-behaved. One of the real troublemakers is libnet which was
> packaged unversioned and has been resisted to be updated until now.

Perhaps it makes sense to update the package using the same binary,
but this time with a symlink.  Then wait five or ten years (a blink of
an eye in Solaris galactic time) and release the update.

NSPR developer guidelines[1] say:

"""Downward Compatibility. Because many different applications,
besides the mozilla client, use the NSPR API, the API must remain
downward compatible across even major releases. This means that the
behavior of an existing public API item in NSPR cannot change. Should
you need to have a similar API, with some slightly different behavior
or different function prototype, then suggest a new API with a
different name."""

In theory, there should be no API changes.  But I guess you know, that
in theory, there's no difference between theory and practice.  In
practice, there is. ;-)

Maciej

[1] http://www.mozilla.org/projects/nspr/eng-process/contributors.html#GeneralGuidelines