[dns-operations] Sad news today: systemd-resolved to be deployed in Ubuntu 16.10

[Willem Toorop]

Florian,

I suspect you have linked against a very richly configured libunbound.
The libevent, libpthread, libpython are all dependencies of libunbound
that you need to explicitly enable when configuring (libevent, the
python module etc.).  I suspect the whole kerberos suite is a dependency
of libpython, but not sure.

The unbound python module is of course of no use to getdns at all.

getdns does not need those.  Newer libunbound will hook into the event
system that getdns uses (which is modular) so there is really no
advantage in linking it against a libunbound which uses libevent.

It is also possible to compile getdns for stub resolution only (the
--enable-stub-only option to configure).  In that case it does not link
with libunbound.  DNSSEC is still available then.

When IDN support is also disabled (--without-libidn), libssl and
libcrypto are the only dependencies (otherwise libidn is still a
dependency).

getdns support for libevent, libev and libuv are all via extra shared
libraries that provide the interface to that event library for getdns.
The do not create an extra dependency on the libgetdns.so.

Just to set this straight ;)

-- Willem

Op 03-06-16 om 16:29 schreef Florian Weimer:
> On 06/03/2016 02:12 PM, Paul Vixie wrote:
>>
>>
>> Ondřej Surý wrote:
>>> I already spoke to Martin, and he is very open about that decision
>>> (it's still very early in the development cycle), so I think that
>>> this still might be reverted if we don't slip into systemd-ranting
>>> and provide reasons why this has bad design (not just bugs).
>>
>> systemd, launchd, and libc, and mpr, and every other place where dns
>> client logic is needed, should just link against getdns, and not try to
>> understand or to improve upon the best available dns client logic.
> 
> That's not very realistic, particularly for libc:
> 
> $ ldd /usr/lib64/libgetdns.so.1
>     linux-vdso.so.1 (0x00007ffdf7d85000)
>     libunbound.so.2 => /lib64/libunbound.so.2 (0x00007f2c78da5000)
>     libidn.so.11 => /lib64/libidn.so.11 (0x00007f2c78b71000)
>     libssl.so.10 => /lib64/libssl.so.10 (0x00007f2c788ff000)
>     libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f2c7849f000)
>     libc.so.6 => /lib64/libc.so.6 (0x00007f2c780d8000)
>     libevent-2.0.so.5 => /lib64/libevent-2.0.so.5 (0x00007f2c77e8d000)
>     libpython3.5m.so.1.0 => /lib64/libpython3.5m.so.1.0
> (0x00007f2c779be000)
>     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c777a1000)
>     libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f2c77554000)
>     libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f2c7726e000)
>     libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2c7706a000)
>     libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f2c76e36000)
>     libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c76c32000)
>     libz.so.1 => /lib64/libz.so.1 (0x00007f2c76a1c000)
>     /lib64/ld-linux-x86-64.so.2 (0x0000561536183000)
>     libutil.so.1 => /lib64/libutil.so.1 (0x00007f2c76819000)
>     libm.so.6 => /lib64/libm.so.6 (0x00007f2c7650f000)
>     libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f2c76300000)
>     libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f2c760fa000)
>     libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2c75edf000)
>     libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2c75cb8000)
>     libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2c75a47000)
> 
> 
> I have not investigated whether it is possible to trim things down.  It
> would probably need custom builds of libunbound and OpenSSL with mangled
> symbols.
> 
> Florian
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs