[csw-maintainers] Shared library placement proposal

[Maciej Bliziński]

2011/2/15 Jonathan Craig <jcraig at opencsw.org>:
> The only section I felt was somewhat harry was the portion that spoke
> about linking to an older library.  This portion pre-supposes a
> solution to this problem when it hasn't really been discussed (at
> least in the context of this policy).

It's a good time to discuss it.

> I think the subject of how to
> enable access to older libraries for end-user developers merits its
> own discussion and/or policy.  The method described in the document
> has some serious downfalls

Could you outline them?

> and I would prefer a method more like the
> one used by ubuntu.  This places the include.h and the libfoo.so link
> into a versioned package like libfoo2.0-dev.  This allows the end-user
> to choose the default development version of the library to use with
> builds by choosing the approriate -dev package.  The libfoo-rt package
> then would only have the libfoo.so.1 file needed by executables.
>
> Example:
> appfoo1
>  /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1)
>
> libfoo1rt

I guess that would be libfoo1 / CSWlibfoo1.

>  /opt/csw/lib/libfoo.so.1
>
> libfoo1-dev
>  /opt/csw/include/foo.h
>  /opt/csw/lib/libfoo.so -> libfoo.so.1
>
> appfoo2
>  /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2)
>
> libfoo2rt
>  /opt/csw/lib/libfoo.so.2
>
> libfoo2-dev
>  /opt/csw/include/foo.h
>  /opt/csw/lib/libfoo.so -> libfoo.so.2
>
> Now libfoo1rt and libfoo2rt can coexist and the end-user can choose
> which library they want to develop against by choosing the appropriate
> -dev package.

In our case it can't be done by including files directly in packages.
If you tried to release the -dev packages like this, your second
package would be rejected with a note that it conflicts with the first
one.  Perhaps an approach using alternatives could be used: place
files elsewhere and provide symlinks.

There's one issue to be addressed: we are using shared build systems
on the buildfarm (e.g. current9s).  It needs to be possible to link to
libfoo.so.2 as well as libfoo.so.1 on a single system, without any
global package manipulation (and root / sudo access).

Maciej