[csw-maintainers] commentary on shared library naming proposal

[Dagobert Michelsen]

Hi Maciej,

Am 27.12.2010 um 12:25 schrieb Maciej (Matchek) Blizinski:
> No dia 26 de Dezembro de 2010 20:50, Dagobert Michelsen
> <dam at opencsw.org> escreveu:
>>> 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?
>> 
>> After reading it two more times I guess it makes sense the way it is.
>> It may be helpful to make this more clear
>>  "The policy or recommendation shall refer to libraries which are
>>   linkable, meaning that the library is meant to, or can be, linked to."
>> by just removing ", or can be,".
> 
> How about removing the "meant to" bit instead?  Even if you don't mean
> a library to be linked to, another package still can linked to it.

As maintainer of a package I would like to be free to say
"this library is really private and I *know* that no one will
link to it" and not be forced to split it.

> By the way, can you think of a way of determining which of the 9
> kerberos libraries are private and which are public?

By looking and reading the docs about the api. There is probably no
automatic way on initial package creation. For Kerberos there are
a ton of packages binding against the published .so libs and only
the shipped binaries within the package binding to the private
libraries, so only time will tell afterwards.

>> Further I recommend a new check that explicit linkage against
>>  /opt/csw/lib/sparcv8plus+vis/libfoo.so.0.2
>> is prohibited from any binary/library not being itself sparcv8plus+vis
>> for any ISA other than the default ones (sparc/i386/sparcv9/amd64).
> 
> That is a whole new branch of functionality I need to implement.
> Currently, checkpkg does not look at architectures when determining
> dependencies.  This feature is slowly crawling towards the top of my
> todo list.

Cool, but I would think of this as a real special case which will
probably won't find many positives.


Best regards

  -- Dago