Does anyone know if there is any particular reason that bitlbee uses
libresolv.a rather than libresolv.so ?
Yes; the fact that Ulrich Drepper thought it'd be a good idea to declare
this API private and unsupported, claiming it's for internal use only,
even though it's documented in various places already, including IIRC
O'Reilly's DNS & BIND.
I can see that as a good reason for using the static version in upstream
bitlbee. Nevertheless debian does appear to provide a libresolv.so with
a proper soname and linking against it does seem to give sane
dependencies from dpkg-shlibdeps so maybe it would be a good idea to use
it in the debian packages. Ccing debian-glibc to see if they have an
opinion on the matter.
> Does anyone know if statically linking libresolv and dynamically linking
> glibc then upgrading glibc is supposed to be supported?
It's never been a problem so far, and the previous BitlBee package went
through several libc6 revisions. TBH I'm more than willing to figure out
some way to drop this strict dependency while continuing to use
libresolv.a. If someone ever decides to change the res API I can always
do a reupload that temporarily disables SRV record lookups, for example.
Is there an easy way to do that? I see the -x flag to dpkg-shlibdeps,
but that would completely eliminate the libc6 dependencies, and that's
not really what I want, of course.
You could always sed it out of debian/substvars between the call to
dpkg-shlibdeps and dpkg-gencontrol but it's a bit ugly to say the least.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
