Jon Bernard <jbern...@debian.org> writes: > 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?
You can run dpkg-gensymbols on a build tree of 0.6.6, copy the resulting symbols file over to a build tree of 0.7.4, and repeat. That said, that approach may well be overkill here. >> 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. I meant that *liburcu*'s rules should run dh_makeshlibs -V; sorry if that was unclear. (That said, it would probably be wise for ltt-control to do the same for the sake of its libraries' own reverse dependencies.) > 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? That would only work if liburcu1 shipped a symbols file with a magic Build-Depends-Package line. > Also, which of these in your opinion is the best/most-proper solution? I might just go for having liburcu1 run dh_makeshlibs -V for simplicity; although that approach can result in overly tight dependencies, that shouldn't be a big deal here. > Thanks in advance, No problem. Please let me know if you have further questions. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
