Runa Sandvik wrote:
> What is the status on this ITP?
hi,
dnscap depends on libbind (not libbind9) to produce meaningful output.
this was included in BIND9 up until the 9.5 release, but not enabled in
the debian bind9 package, and anyway unstable now has BIND9 9.6 which
removed libbind entirely.
libbind is now available as a separate product from ISC, which i plan to
file an ITP for if the BIND9 maintainer (Cc'd) is not interested in
packaging it. (and unfortunately the bind9 source package ships a
binary package called libbind-dev which will need to be worked around
somehow.)
additionally, glibc 2.7's libresolv.so as shipped in lenny does not
allow linking against the symbols dnscap needs (ns_initparse() et al),
but as of (i believe) glibc 2.9-2, i think this was relaxed:
glibc (2.9-2) unstable; urgency=low
[...]
* debhelper.in/*symbols*, rules.d/debhelper.mk: allow linking against
private symbols again, but with a strict dependency on the upstream
version.
[...]
-- Aurelien Jarno <aurel32@debian.org> Fri, 20 Feb 2009 22:25:19 +0100
(see also #291609)
i need to do some more testing to see how stable this is (and it would
certainly seem to make backports much more difficult) but i'll probably
have to use libbind, as i have in mind packaging other software which
may depend on newer versions of libbind. (the glibc libresolv.so is a
fork of a much earlier version of the code now available in libbind.)
also note that my employer (ISC) is the upstream for the software
(dnscap, libbind, BIND9) mentioned in this email.
--
Robert Edmonds
edmonds@debian.org
Attachment:
signature.asc
Description: Digital signature