[csw-maintainers] Shared library placement proposal

Dagobert Michelsen dam at opencsw.org
Fri Feb 4 09:50:16 CET 2011


Hi,

Am 04.02.2011 um 09:22 schrieb Peter FELECAN:
> Philip Brown <phil at bolthole.com> writes:
>> On 2/3/11, Peter FELECAN <pfelecan at opencsw.org> wrote:
>>> 
>>>> We need to have the library visible in both locations, to avoid
>>>> confusion to both users, and potential auto-detect scripts. Ones that
>>>> tend to have single flags like --use-libfoo=/prefix, rather than 3
>>>> separate flags for --usr-libfoo-lib, --use-libfoo-include,
>>>> --use-libfoo-iforgettheotherthing
>>> 
>>> I was quite opposed to this specific directories for different
>>> versions but lived with its inconveniences. Now that we have
>>> alternatives, it's really a PITA.
>>> 
>>> Anyhow, what I wish is to not make it mandatory to separate different
>>> versions of the same project, which make sense to be installed
>>> simultaneously, in different directories but to be able to use
>>> alternatives and shared objects in /opt/csw/lib as a accepted solution.
>> 
>> well, we may have different reasons for it, but seems like in that
>> case, we both agree on something:
>> 
>> Forcing the "actual file", rather than a symlink, into /opt/csw/lib,
>> for *all* cases, is bad. Symlinks are more appropriate in some cases.
>> 
>> Whether that symlink is done via "alternatives" or some other means,
>> is not an immediate issue to me. The immediate concern to me is that
>> the proposal as written, prohibits that sort of thing, and so needs to
>> be changed.
> 
> Indeed, we cannot have a strict, mandatory policy on this, rather a
> recommendation which is still a policy. Consequently, your proposition
> of modification cannot be as strong as you proposed, i.e., imposing the
> symbolic links instead of the real files.
> 
> As for using alternatives for shared libraries, I don't know what to
> think. I thought that alternatives are more appropriate to executables
> but I must confess that thoroughly exploring alternatives is one of my
> objectives.


I don't see the need for alternatvies on shared libraries. The existing
use case for different levels of functionality can better be done by
AUX linkage. Or are there other issues?


Best regards

  -- Dago



More information about the maintainers mailing list