[csw-maintainers] commentary on shared library naming proposal
Dagobert Michelsen
dam at opencsw.org
Sun Dec 26 21:50:59 CET 2010
Hi Maciej,
Am 26.12.2010 um 18:42 schrieb Maciej (Matchek) Blizinski:
> No dia 26 de Dezembro de 2010 14:54, Dagobert Michelsen
> <dam at opencsw.org> escreveu:
>> 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?
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,".
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).
Best regards
-- Dago
More information about the maintainers
mailing list