[csw-maintainers] commentary on shared library naming proposal

[Maciej (Matchek) Blizinski]

No dia 26 de Dezembro de 2010 14:54, Dagobert Michelsen
<dam at opencsw.org> escreveu:
> Hi Maciej,
>
> Am 26.12.2010 um 13:12 schrieb Maciej (Matchek) Blizinski:
>> I would like us to have a cleaned up shared library packaging
>> documentation.  The current state is:
>>
>> http://www.opencsw.org/extend-it/contribute-packages/build-standards/shared-libraries/
>> - needs to be updated
>>
>> http://wiki.opencsw.org/packaging-shared-libraries
>> - is up to date, but it's still declared to be a proposal rather than
>> our standard.
>>
>> What's the status of the proposal - have we accepted it?  Is more
>> discussion needed?  Do people have suggestions to change the text on
>> the wiki?
>>
>> Since this subject has been under an intensive discussion, it's best
>> if suggestions for changes are posted here and agreed before the wiki
>> page is modified.
>
> I would like to have a special case added for exclusion of shared libraries which
> are used only from within the package and which are bumped on every
> new release. One example is MIT Kerberos, which has a couple of
> externally used libraries which are synchronized, and some internal-only
> libraries which make no sense to be split because they are used only
> by the Kerberos binaries from within the package. The API for these
> is also not "open" for 3rd applications.

It is an interesting example.  One of the criteria for splitting of
shared libraries is whether it's a library other binaries can link
against[1].  If a library is never linked against, there is no benefit
in splitting it off.

Checkpkg currently uses library location to determine whether library
is linkable.  I'm not sure why private kerberos libraries are put in
the public space.  In theory, anybody could add an "-lfoo" option to
the compiler invocation, and that would bring us back to the original
problem.

The wiki page currently says:

"""The policy or recommendation shall refer to libraries which are
linkable, meaning that the library is meant to, or can be, linked to.
Shared objects in private directories, such as
/opt/csw/lib/someproject/foo.so (think Python modules) are not shared
libraries which other projects may link to, and therefore there is no
benefit in placing them in separate packages."""

I think that the kerberos case is handled that this bit of text -
these libraries aren't linkable, and splitting them off doesn't win us
anything.  Do you have any wiki page modification in mind, to
emphasize implications for cases such as Kerberos?

[1] http://wiki.opencsw.org/packaging-shared-libraries#toc7