[csw-maintainers] Shared library placement proposal

Peter FELECAN pfelecan at opencsw.org
Tue Feb 8 09:46:37 CET 2011


Jonathan Craig <jcraig at opencsw.org> writes:

> On Mon, Feb 7, 2011 at 11:07 PM, Philip Brown <phil at bolthole.com> wrote:
>> On Mon, Feb 7, 2011 at 7:25 PM, Ben Walton <bwalton at opencsw.org> wrote:
>>>
>>> My preference, as the whole point of this proposal is to have more
>>> libraries available in /opt/csw/lib, is to prefer the files to be
>>> placed in /opt/csw/lib and the symlinks (if any) to be in
>>> /opt/csw/special/lib/.
>>>
>>> Does anyone think this should be the opposite by default?
>>
>> yes. I've already written this, AND I've already written why.
>> Because that is the "normal" way that programs install things, when
>> you compile with
>>  configure --prefix=/opt/csw/prefix
>>
>> That is the "normal" location ,therefore that should be the "real" location.
>> This is consistent with standard behaviour. For example,
>> /usr/openwin/lib. that is/was the "real" location of the libX11
>> libraries, but for convenience, symlinks were made from other
>> locations pointing to there.
>> We are in the same situation. We basically want a reference in
>> /opt/csw/lib, for convenience.
>>
>
> I concur.  Libraries should be placed in their package specific
> subdirectory as the package install would have it.  For convenience, a
> symlink from our global library directory (/opt/cw/lib) should be made
> to the actual file.
>
> The primary reason being that this allows easier integration of
> multiple versions.  If you reverse this and force the actual library
> into /opt/csw/lib then you will have to move this library to its
> package/versioned subdirectory before overwriting.  This would be a
> logistical nightmare.
>
> As to libraries with SONAME collisions I don't know whether its better
> to not create any symlinks or always create symlinks to the newest
> version (or possibly last installed).  Its a coin toss between
> problems finding libraries during builds and the possibility that
> you'll break an existing application by installing a newer version of
> the library.  Having said that, I guess I would lean towards
> operational stability and not create any symlinks.

What about stating that a symbolic link *should* be made in a sense or
another if the need arise but, as it implies, is not mandatory.
-- 
Peter


More information about the maintainers mailing list