Control: tags -1 - patch On Mon, Nov 14, 2016 at 12:22:58PM +0100, Raphael Hertzog wrote: > Please find two patches attached. > > I checked that the command below was failing with the current dpkg-dev > and it did no longer fail with the updated one. > > $ sbuild -d sid --add-depends=usrmerge --chroot-setup-commands="sed -i > 's#^/usr##;t;s#^/lib#/usr&#' /etc/ld.so.conf.d/x86_64-linux-gnu.conf" dash > > I believe my patch to be correct and clean.
Thank you for taking the time to come up with a solution. Still, the approach is wrong. dpkg-shlibdeps relies on dpkg -S to look for the owning package of a library. We know that dpkg -S works badly with symlinks and that has been why using symlinks for critical paths has never been supported nor the default. The /usr merge changes that. On a merged system, you get things like: $ dpkg -S `which false` dpkg-query: no path found matching pattern /usr/bin/false $ This confuses both human and automated users of dpkg -S including dpkg-shlibdeps. Once dpkg -S produces reasonable output for such paths, dpkg-shlibdeps will just work. Patching dpkg-shlibdeps papers over the bug, it doesn't fix it. Your patch is an improvement in clarity and pinpoints the cause, but that's about it. dpkg -S has users beyond dpkg-shlibdeps such as needrestart, massxpert, pcp, lxc, debian-handbook, etc (as a quick codesearch "dpkg .*-S" and manual inspection reveals). Papering over the issue in dpkg-shlibdeps and trying to fix all consumers does not look viable to me. Thus I am removing the patch tag in the sense that it doesn't solve the problem in a way suitable for stretch. > It's easier to push work upon others... to be honest the code (that I > wrote) in dpkg-dev that tries to identifiy the canonical version of the > library is also somewhat hackish. That's what you do, indeed. dpkg-shlibdeps is known to be very fragile. Last time Guillem touched it in fairly trivial ways, stuff broke. Your patch hasn't seen extensive testing yet and it changes the search order, which is a key aspect of its fragility (in particular due to multilib). Felipe has run some tests, but that's about it. Part of what resulted in a delay here is that nobody ran the tests and when I had time to run them, other changes in unstable (gnutls28 Build-Depends: libunbound-dev) broke my test cases. Testing it now, but I'm quite annoyed by the amount of breakage pushed on me. Helmut
