Control: tag -1 + patch Control: severity 134758 + important I add the patch tag back because this bug is about "dpkg-shlibdeps" being broken by usrmerge. Not about dpkg -S being broken. I agree that dpkg -S ought to be fixed too... but this corresponds to bug #134758. I'm thus raising the severity of #134758 to important.
On Mon, 12 Dec 2016, Helmut Grohne wrote: > 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. [...] > 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. Yes, dpkg-shlibdeps relies on dpkg -S and knows how to parse its output. dpkg -S being a very old interface, I believe that any "fix" in that interface will break something... we will have to adapt code to understand the new lines of output or we will have to make those new lines conditional on a new command line option. So I don't buy your argument of let's just fix "dpkg -S" and everything will be fine. We will have to fix "dpkg -S" and any code that parses the output of "dpkg -S". > Your patch is an improvement in clarity and pinpoints the cause, but > that's about it. The patch replaces a fragile approach trying to avoid non-canonical paths with a more solid one where we look up all possible paths against the dpkg database. It improves dpkg-shlibdeps whether or not we end up using usrmerge for stretch. It should be merged. Following your suggestion on IRC, I am fine for it to be committed with limited review and then being reverted if it breaks anything (I'm also available to handle any subsequent bugreport). > 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). debian-handbook (my book) documents it :-) > 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 As I said, I believe that all consumers will have to be fixed (or at least reviewed to ensure they are not confused by the new output we would have). > > 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). What search order does it change? It still looks up libraries in the same ordered list of directories. > broke my test cases. Testing it now, but I'm quite annoyed by the amount > of breakage pushed on me. Sorry for this, but that's just our life of free software contributors, we constantly have to adapt to changes made by others. It's hard to avoid it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
