[csw-maintainers] Shared library placement proposal

[Jonathan Craig]

2011/2/15 Maciej Bliziński <maciej at opencsw.org>:
> 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.
>

We can certainly discuss it but do we wish to hold up progress on
library placement for a sidebar discussion on how to support multiple
versions of a given runtime library for developers?  One of the goals
was to decouple the shared library issue from how to support multiple
versions of a given application and then the proposal drives right
into this issue.

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

The original example of devoid of packaging information.  I'm assuming
at least two packages exist (libfoo1, libfoo2), but which one owns the
/opt/csw/lib/libfoo.so -> libfoo.so.N?

The example layout supposes the maintainer do a lot of monkeying about
to shuffle libraries around and, pardon my emotional response, feels
messy.  If the library includes its own private prefix
(/opt/csw/{prefix}) then some stuff is shuffled to
/opt/csw/lib/{prefix} and other stuff is kept in
/opt/csw/{prefix}/lib.  It feels confusing and fractured, but thats
just my opinion and I'm willing to hear counter arguments.

Could you talk through the design choices  involved with the layout
shown in the proposal example over alternatives?

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

Cant be done given the existing implementation or cant be done at all.
 Should we limit our solutions to the existing code if it precludes
the implementation of a more elegant solution?

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

Hmm, this is a tough one because its a situation we have as a
maintainer community that isn't as much of an issue for an end user.
An end user can install/re-install the -dev package as needed.  Access
to the shared library could be handled by creating a "lib" directory
in the package build space that creates the symlink to whatever
version of the shared library.  This doesn't solve the issue of
conflicting include files.  For the build farm could we have
installation of development packages into private root directories
that are added to the using -L/-I options but expect to find their
runtime libraries in /opt/csw/lib using -R.

>
> Maciej
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.