dpkg-shlibdeps couldn't find library ... warning vs error
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?
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?
regex 2 (/^(.*)-(\d.*)\.so$/)
The terminating so on this regex helps limit its capture but again should the
groups be limited to digits only?
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 am willing to create a patch but before I assume I know what it "should" be
doing I wanted to see how the maintainers felt.
Reply to: