Re: dpkg-shlibdeps couldn't find library ... warning vs error

[Guillem Jover <guillem@debian.org>]

Hi!

On Wed, 2019-06-26 at 14:58:34 -0400, Crim, Christopher wrote:
> I am trying to understand the regex rules in the function split_soname from 
> dkpg-shlibdeps.pl.  Working with an old corporate code base that has yet to 
> adopt any versioning, all of the shared objects are named <object>.so.  When 
> attempting to package on a box that does not yet have the dependent packages 
> installed dpkg-shlibdeps will throw warnings, "dpkg-shlibdeps: warning: 
> couldn't find library <lib>.so needed by ..." but packaging will still succeed.  
> We have few shared objects that have ".so." as part of their name.  When dpkg-
> shlibdeps encounters these dependencies the warning becomes an error, "dpkg-
> shlibdeps: error: couldn't find library <lib>.so needed by ..." and packaging 
> fails.  I traced this down to the split_soname function which checks 2 regex 
> comparisons.  The shared objects that only throw warnings fall into the "else" 
> clause of the function.  The ones that fail fall into the first if clause which 
> as regex 1.  What were these regexs meant to match?

If the installed packages have no shlibs or symbols file information
then dpkg-shlibdeps cannot know what dependency information to inject,
which means the generated binaries will end up with missing/incorrect
dependencies. See below for the distinction.

> regex 1 (/^(.*)\.so\.(.*)$/):
> was this meant to capture shared objects with so number and revisons such as 
> libc.6 or libbz2.so.1.0.4?  If so, should the values after "so" be restricted 
> to numbers? 

It cannot be restricted to numbers only because the version might
include other characters.

This format is the one used commonly for public and stable shared
libraries, where the format is <name>.so.<version>, and then there's
at least one symlink of the form <name>.so pointing to the former and
used by other objects to link to, that gets them the latest <version>.

The key here is that the SONAME might only include part of the
SOVERSION, depending on where the <name>.so symlink points to, so you
could have:

  libfoo.so.1.2.3
  libfoo.so.1
  libfoo.so → libfoo.1

Because these are public interfaces they are expected to have
dependency information available.

> regex 2 (/^(.*)-(\d.*)\.so$/)
> The terminating so on this regex helps limit its capture but again should the 
> groups be limited to digits only?

This is the format commonly used for private and/or unstable shared
libraries, where the whole version is encoded in the SONAME. So you
could have:

  libbar-1.2.3.so
  libbar.so → libbar-1.2.3.so (optionally, otherwise you might be
                               required to specify the whole SONAME)

As these are private/unstable interfaces they are to be used at your
own risk, so that's why they are just warnings.

>  I have tried searching for inforamtion related to to naming conventions for 
> shared library names but the best I can come up with is that they need to be 
> prefixed with "lib" and suffixed with ".so" and possibly the so number and 
> revision.  A name such as "libcom.debian.foo.bar.so" should be valid.  If not 
> I would appreciate being pointed to such requirements.

I'm not sure now, there's anywhere properly documenting these details.
I don't think the debian-policy manual contains rationale for these.
I've for now locallt documented the split_soname() function, willcheck
whether one of the man pages can also be improved.

Hope that helps. Even though I'm not sure it resolved your issue at
hand? :)

Thanks,
Guillem