[csw-maintainers] Shared library placement proposal

[Maciej Bliziński]

2011/2/4 Peter FELECAN <pfelecan at opencsw.org>:
> 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.

I agree that the policy regulating files vs symlinks should not be
strict and mandatory.  If a maintainer wants to have a specific layout
of files and symlinks and has a good reason for it, they should be
allowed to do this.

In the typical case, if we have a library regular file and a symlink
to it, it's a transitional state, in which the regular file is in the
target location, and symlinks provide backward compatibility.  If
there is no transition necessary, putting a symlink where the file is
needed, and hiding the regular file elsewhere sounds like a suboptimal
practice.

As far as the policy is concerned, we could find a wording which:

- Recommends that regular files are put into /opt/csw/lib and that
symlinks are not used without necessity
- Allows symlinks to be used, if there is a reason for such use

> 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.

As far as supporting multiple versions of the same software is
concerned, shared libraries already have a mechanism for it: SONAMEs.
It may happen that two different versions of the same software provide
libraries with the same SONAME.  For example, PostgreSQL 8.3, 8.4 and
9.0 provide libpq.so.5.  In this case, we provide libpq.so.5 built
from one of them, and we simply don't install other two.  8.3 client
software will be happily using 9.0 libraries.  There's no need for
alternatives, at least in this case.

Maciej