[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: