On Thu, Sep 19, 2013 at 4:29 PM, Guillem Jover <guil...@debian.org> 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, I
am _only_ proposing that dpkg-shlibdeps should not give up on
processing them because it cannot extract a version number from its
name. 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.
zw
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
