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
