* 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.
Thanks again!
--
Jon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
