Your message dated Sun, 15 Jun 2014 03:42:12 +0200
with message-id <[email protected]>
and subject line Re: Bug#723783: dpkg-shlibdeps: more tolerant soversion
extraction
has caused the Debian Bug report #723783,
regarding dpkg-shlibdeps: more tolerant soversion extraction
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
723783: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723783
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.17.1
Severity: wishlist
File: /usr/bin/dpkg-shlibdeps
Tags: patch
Some shared libraries are stuck with nonstandard names for binary
compatibility's sake; a good example is libnspr4, which ships
/usr/lib/ARCH/libplc4.so, .../libplds4.so, and .../libnspr4.so. (The
SONAME field in the ELF headers in each case matches the filename.) I
do not propose to make all the changes (not least to Policy) to make
this fully supported, but I think dpkg-shlibdeps should not throw up
its hands at such libraries. This is the minimal patch to do that.
For shared libraries that have no version number at all in their name,
we don't want to equate that to version "0", so I've opted to make
split_soname return "." for $libversion. This won't actually get
written to a shlibs file (since this is -shlibdeps, not -makeshlibs)
and it sorts ASCIIbetically before "0".
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dpkg-dev depends on:
ii base-files 7.2
ii binutils 2.23.52.20130828-1
ii bzip2 1.0.6-5
ii libdpkg-perl 1.17.1
ii make 3.81-8.2
ii patch 2.7.1-3
ii xz-utils 5.1.1alpha+20120614-2
Versions of packages dpkg-dev recommends:
ii build-essential 11.6
ii clang-3.2 [c-compiler] 1:3.2repack-11
ii fakeroot 1.19-2
ii gcc [c-compiler] 4:4.8.1-3
ii gcc-4.6 [c-compiler] 4.6.4-4
ii gcc-4.7 [c-compiler] 4.7.3-7
ii gcc-4.8 [c-compiler] 4.8.1-10
ii gnupg 1.4.14-1
ii gpgv 1.4.14-1
ii libalgorithm-merge-perl 0.08-2
Versions of packages dpkg-dev suggests:
ii debian-keyring 2013.07.31
-- no debconf information
--- dpkg-1.17.1.o/scripts/dpkg-shlibdeps.pl 2013-07-28 05:56:47.000000000 -0400
+++ dpkg-1.17.1/scripts/dpkg-shlibdeps.pl 2013-09-19 14:11:34.583442876 -0400
@@ -672,6 +672,10 @@
return wantarray ? ($1, $2) : 1;
} elsif ($soname =~ /^(.*)-(\d.*)\.so$/) {
return wantarray ? ($1, $2) : 1;
+ } elsif ($soname =~ /^(.*?\D)(\d+)\.so$/) {
+ return wantarray ? ($1, $2) : 1;
+ } elsif ($soname =~ /^(\D+)\.so$/) {
+ return wantarray ? ($1, ".") : 1;
} else {
return wantarray ? () : 0;
}
--- End Message ---
--- Begin Message ---
Hi!
On Sun, 2013-09-29 at 18:10:05 -0400, Zack Weinberg wrote:
> On Thu, Sep 19, 2013 at 4:29 PM, Guillem Jover <[email protected]> wrote:
> > On Thu, 2013-09-19 at 14:43:09 -0400, Zack Weinberg wrote:
> >> Some shared libraries are stuck with nonstandard names for binary
> >> compatibility's sake; a good example is libnspr4, which ships
> >> /usr/lib/ARCH/libplc4.so, .../libplds4.so, and .../libnspr4.so. (The
> >> SONAME field in the ELF headers in each case matches the filename.) I
> >> do not propose to make all the changes (not least to Policy) to make
> >> this fully supported, but I think dpkg-shlibdeps should not throw up
> >> its hands at such libraries. This is the minimal patch to do that.
> >
> > While preserving two-way compatibility might make some sense, these
> > SONAMEs are still broken, and go against how shared libraries usually
> > work on Unix systems (these are most of the time Windows-style library
> > versioning). There's always the option to have at least one-way
> > direction compatibility, i.e. use a proper SONAME in Debian and provide
> > compat symlinks for external binaries. Also such libraries can still use
> > symbols files which use the full SONAME, so they sidestep the errors.
>
> I think you have misunderstood the feature request here. I am _not_
> proposing that these incorrectly-named libraries be fully supported,
As I've mentioned above, these are already partially supported as long
as one uses a symbols file instead of a shlibs file, which means that…
> I am _only_ proposing that dpkg-shlibdeps should not give up on
> processing them because it cannot extract a version number from its
> name.
…this will not hold true, as dpkg-shlibdeps can then handle those
shared libraries perfectly well. See the example that you yourself
provided, libnspr4.so in package libnspr4, it only provides a symbols
file and no shlibs file:
$ dpkg-query --control-list libnspr4
$ dpkg-query --control-show libnspr4 symbols
And dpkg-shlibdeps handles those w/o warnings or complaints as can be
seen from the rpm build log, for example:
<https://buildd.debian.org/status/fetch.php?pkg=rpm&arch=i386&ver=4.11.2-3&stamp=1398764719>
> As far as I can tell, the only consequences of this patch are:
> (1) dpkg-shlibdeps does not spew errors on a package containing a
> library with a name like this (note that lintian will still complain
> about it; note also that there can be hundreds of such errors in a
> package with both an awkwardly-named library and a binary depending on
> it -- possibly one per symbol satisfied by the library), (2)
> ${shlibs:Depends} may under some circumstances be more accurate.
>
> Please reconsider.
Well, I've still not seen a compelling reason to do so given the
above. I'm preventively closing this now, but if there's any new
information or arguments, please feel free to reopen.
Thanks,
Guillem
--- End Message ---
