[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