* Aaron M. Ucko <u...@debian.org> wrote: > Package: liburcu1 > Version: 0.7.4-1 > Severity: serious > Justification: Policy 8.6 > > lttng-tools's postinst fails on my system, which still has liburcu1 > 0.6.7-2 (from testing), demonstrating that liblttng-ctl0 needs a > versioned dependency on liburcu1. I would say liburcu1 is primarily > at fault here (though lttng will need a round of binNMUs once you've > fixed it).
Thanks for catching this, I understand the problem conceptually, but I have couple of questions about how to properly handle it. > Could you please ensure that dpkg-shlibdeps will yield sufficiently strict > dependencies on liburcu1 by either adding a .symbols file that will direct it > to do so selectively. Is there an easier way of doing this without searching through the source to find all liburcu calls and then pinning them to a specific version in the symbols file? - or is that how it's done? > or simply insisting on a versioned dependency in its .shlibs file (e.g., by > running dh_makeshlibs -V). This will yield a file containing: "liblttng-ctl 0 liblttng-ctl0 (>= 2.1.0~rc4)" But that will not help me with the liburcu dependency, which should likely be 0.7.4. It's not clear to me how to get dh_makeshlibs to do the right thing. My first thought was that "Build-Depends: .. liburcu-dev (>= 0.6.6)" is too lenient, and that version should be bumped. I could then release ltt-control version 2.1.0-2 with this change, and avoid the binNMUs, no? What am I missing? Also, which of these in your opinion is the best/most-proper solution? Thanks in advance, -- Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
