* Jon Bernard <jbern...@debian.org> wrote: > * Aaron M. Ucko <u...@debian.org> wrote: > > 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. > > Ok, this makes sense. So just to be clear, here are the steps I plan to > follow: > > 1. In liburcu source, add "-V" to dh_makeshlibs to set strict symbol version > dependencies on this particular version > > 2. Rebuild ltt-control against the new liburcu, which will pull in liburcu's > shlibs and cause ltt-control to depend on that specific version of > liburcu. > > 3. Request binNMU for ltt-control. > > Is step 3 necessary, will the updated ltt-control not sort this out? That's > the > only piece I don't quite follow.
Because step 2 requires no source changes, just a rebuild. Thus, binNMU. I believe I understand now. Thanks Aaron! -- Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
