[csw-maintainers] Shared library placement proposal

[Peter FELECAN]

Maciej Bliziński <maciej at opencsw.org> writes:

> 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

Have you, or anyone else encountered this case? In the affirmative
please provide the example.

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

I would like to emphasize the term *should* which is weaker than
*must*. Again, if it's a should I agree.
-- 
Peter