On Sat, 29 Oct 2011, Robert Edmonds wrote:
Paul Wouters wrote:
I don't think there is a valid reason for the unbound daemon not
to link against the unbound library instead of including a static
copy.
actually, i can think of a reason: so that the unbound daemon can use
more "advanced" options (external event library, python integration)
while the libunbound library doesn't. in fact, i've just uploaded a new
version of the debian unbound package that minimizes the library
dependencies of libunbound while leaving unbound unchanged.
e.g., if libunbound dynamically links against libev, you cannot
dynamically link an executable against libunbound and libevent, since
the symbols in libev and libevent would conflict. (i think there is
also a similar possibility with libpython2.6 / libpython2.7, but i
believe libssl0.9.8 / libssl1.0.0 aren't affected because libssl uses
versioned symbols.)
I see your point, but I'm not sure how packaging would deal with that,
other then maintaining two different compiles of libunbound on the same
system - and maintaining the "static" copy inside the daemon.
For Fedora/RHEL, I've added a hard Requires: so that the libs and the
daemon package will never be of a different version.
Paul
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
