[csw-maintainers] Shared library placement proposal

[Maciej Bliziński]

2011/2/3 Peter FELECAN <pfelecan at opencsw.org>:
> Maciej Bliziński <maciej at opencsw.org> writes:
>
>> 2011/2/3 Peter FELECAN <pfelecan at opencsw.org>:
>>> I globally agree with the exception of the handling of private shared
>>> libraries: it should be optional to put these in a specific directory
>>
>> If you put a private shared library in /opt/csw/lib, wouldn't it
>> effectively make it a public one?
>>
>> Once a library is in /opt/csw/lib, you can add a -l flag to the linker
>> and link against it in the same way you link against public libraries.
>>  A private library in /opt/csw/lib sounds like an oxymoron to me.
>>
>> However, there's nothing that prevents you from putting any shared
>> library of your choice into /opt/csw/lib, as long as it's packaged
>> according to the standard - meaning, it's in a separate package.
>
> I see 2 reasons for which a private library can be let in /opt/csw/lib:
>
> 1. nothing precludes to use it if the API is public; if the provider
>   considers it private he had put it in a private directory and not
>   supply an API

If a library has a public API, then by definition the library is
public, I guess we both agree on that.  Regarding the second part, I
would not necessarily rely on the locations of libraries as installed
by the upstream 'make install' target.  I've seen projects that
install private libraries into /opt/csw/lib, and vice versa, public
libraries installed into /opt/csw/lib/foo.  We can instead analyze the
upstream project's code to determine which libraries are shared and
which are public.  Talking to upstream developers is also an option.

> 2. making mandatory this kind of policy for private library
>   unnecessarily complexify packaging vs Debian which doesn't have
>   this kind of policy.

It does add some complexity, I agree.  But it does it for a good
reason: we want to avoid other projects accidentally linking to a
library which was thought to be private, because once this happens,
you need to take the following steps to recover:

1. Move the once-thought-to-be-private library from CSWfoo to a
separate package (e.g. CSWlibfoo1)
2. Make CSWfoo depend on CSWlibfoo1 (for backward compatibility)
3. Release CSWlibfoo1, re-release CSWfoo
4. File a bug with CSWbar (the package which accidentally linked to libfoo.so.1)
5. Wait for new CSWbar to be released
6. Remove the dependency on CSWlibfoo1 from CSWfoo
7. Re-release CSWfoo

This kind of procedure is annoying, and I'm sure everyone would like
to avoid it, if possible.

The mistake in the other direction (putting a public library in a
subdirectory), has less impact.  To recover:

1. Move the library from CSWfoo to CSWlibfoo1
2. Make CSWfoo depend on CSWlibfoo1 (only if necessary, e.g. binaries
from CSWfoo need libfoo.so.1)
3. Release CSWlibfoo1, re-release CSWfoo

In the long run, this policy would be a time saver, for both
maintainers: the maintainer of CSWfoo (+CSWlibfoo1), and the
maintainer of CSWbar.

Regarding Debian, if you read the "10.2 Libraries" section[1] of the
Debian policy, you'll see the following paragraph:

"Shared object files (often .so files) that are not public libraries,
that is, they are not meant to be linked to by third party executables
(binaries of other packages), should be installed in subdirectories of
the /usr/lib directory. Such files are exempt from the rules that
govern ordinary shared libraries, except that they must not be
installed executable and should be stripped."

[1] http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries