[csw-maintainers] An idea for a shared libraries policy

[Maciej (Matchek) Blizinski]

No dia 28 de Setembro de 2010 10:57, Philip Brown <phil at bolthole.com> escreveu:
> On 9/28/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>>
>> Yes, I support that.  I did a quick search and found that Debian policy
>> says:
>>
>> "The run-time shared library must be placed in a package whose name
>> changes whenever the SONAME of the shared library changes. (...)
>> Normally, the run-time shared library and its SONAME symlink should be
>> placed in a package named librarynamesoversion, where soversion is the
>> version number in the SONAME of the shared library."
>>
>> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime
>
>
> Hmm. Well, it's a good start.

By "start", do you mean only the quotation, or the whole thing?

> There are two unmentioned issues that come to my mind:
> 1. where the name is just Really Stupid :)

I understand you reserve a right to say "no".

> 2. where the name may not neccessarily imply, "hey this is a library".

Can it ever not begin with "lib"?  I thought that when you link using
the -lfoo flag, the linker will only link with libfoo.so, nothing
else.  Hence, the file must be named libfoo, and so must the package.

> For those cases, I'm a little leery of going with a hard line "name
> must exactly match SONAME" policy.
> I think that having that as a guideline would be okay though.
>
>
>> I could write a checkpkg test: if there's a shared in /opt/csw/lib
>> (including ISA subdirectories), and has a SONAME, the pkgname must
>> conform to:
>>
>> CSWlibrarynamesonameversion or CSWlibraryname-sonameversion
>>
>
> See above. I dont think it should be put as a blocking checkpkg test.
>
> Also, theres the issue that this is an OPTIONAL split-out.
> We were talking about doing this for *some* shared libs, but not all.

With checkpkg, all errors are equal and all can be overridden the same
way.  This way, no test is a blocking one.  I try to keep the false
positive rate to a minimum, but without giving up the promotion of our
policies.  In this case, if checkpkg displays an error about the
package name not matching the shared library within it, the maintainer
will still be able to override the error and do whatever he wants.
The role of checkpkg is only a supporting one, and it's ultimately
humans who make the decisions.

> But just to be nitpicky...
>
>> If it's not under /opt/csw/lib, or is not a binary, or not a shared
>> library, or doesn't have a soname, then the rule doesn't apply.
>
> If it doesnt have a soname, then things default to using the filename,
> I believe. so we'd still need to have the package name change if the
> filename changed.

Right, and a new package is created.  The old package stays around
with the old name, until it becomes unreferenced and obsolete.

I wrote an example implementation of that, worked nicely on a couple
examples, but I haven't yet run it against the whole catalog. Here's
an excerpt from a unit test:

+    self.error_mgr_mock.ReportError(
+        'shared-lib-wrong-pkgname',
+        "file=opt/csw/lib/libneon.so.26.0.4 pkgname=CSWneon "
+        "expected=['CSWlibneon26', 'CSWlibneon-26']")