[csw-maintainers] Shared library placement, take 3

[Jonathan Craig]

On Wed, Jul 20, 2011 at 2:06 PM, Peter FELECAN <pfelecan at opencsw.org> wrote:
> need to use different versions on their own systems. As always, look how
> Debian solved the issue.

There are two use cases for this problem:

Unique SONAMEs ) This is the better behaved use case.  In this
situation multiple versions of the shared libraries can co-exist in
the same directory.  So lets assume we have the app "foo" that
provides "libfoo" and has a version 1 & 2.

package        contents   dependency
foo1             bin           depends on libfoo1
foo2             bin           depends on libfoo2
libfoo1          so
libfoo2          so
libfoo1-dev    header     depends on libfoo1, conflicts libfoo2-dev
libfoo2-dev    header     depends on libfoo2, conflicts libfoo1-dev

If debug versions of so's then:
libfoo1-dbg   debug-so   conficts with libfoo1 (and libfoo1 conflicts with it)

This allows multiple bin/so versions to be installed and one version
of the headers.  We could extend this with CSWalternatives to allow
switching between header versions but could be confusing if you assume
the version you want is the current version.

Non-Unique SONAMEs) Bad developer, bad.  Oh well, the packager must
still deal with it.  I'm not sure of an example package like this to
check against my ubuntu catalog.  This situation calls for either
making the versions exclusive (using conflicts with) or configuring
them for there own tree.  Using alternatives is a risky undertaking
because it will almost always eventually cause grief. If alternatives
puts the .so in a common lib directory and a user builds against it
then changes the alternative choice, whatever they've built will
break.

Ultimately, if the library is well behaved then I do think its best to
place it in a common directory (/opt/csw/lib).

Jon