[csw-maintainers] Shared library placement, take 3

[Maciej Bliziński]

Em 20/07/2011 20:08, "Jonathan Craig" <jcraig at opencsw.org> escreveu:
>
> 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.

What if two maintainers are building packages at the same time and each one
needs a different version of a library?

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

In the general case, it is possible to inject an additional soname number to
make the sonames unique.

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

Yes, alternatives do not look like a good choice, neither for .so symlinks,
nor for libraries.

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

Cool. There is one case which needs consideration: gcc C++ libs vs Solaris
Studio C++ libs. If we compile the same sources with both compilers, we will
get a soname conflict. What should we do: put gcc libs into e.g.
/opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in
/opt/csw/lib? (Or is there another solution?)

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110721/e0daa4cb/attachment-0001.html>