Package bind-dyndb-ldap from src:bind9. (Closes: #1014503)

This should get rid of rebuild-nmu's and hopefully bring some sanity into maintaining the dyndb-ldap plugin.

The workflow goes something like this:

• bump bind9 to new upstream
• find that the plugin fails to build
• run debian/sync_dyndb-ldap.sh (syncs with upstream master)
• check that quilt patches still apply and fix if not
• run fakeroot debian/rules gen-dyndb-orig
• dpkg-buildpackage -S
• hope the build passes now

if it doesn't then dyndb-ldap/ needs to be patched

after re-reading the emails about this, I see that the license (GPL2 vs MPL2) would be a blocker here?

@ondrej any comment?

For instance 389-ds-base is GPL3+ for the most parts, but also includes chunks that are licensed under MPL-2.0, Apache-2.0/MIT etc., so I don't see how mixing licenses could be an issue here?

The comment GPL vs MPL was mainly about the inability to merge bind-dyndb-ldap into upstream. However, adding bind-dyndb-ldap directly into BIND 9 package seems like a huge liability, especially the part here:

if it doesn't then dyndb-ldap/ needs to be patched

So, say, there's a critical security update of BIND 9 and bind-dyndb-ldap fails to build; should we break bind-dyndb-ldap or should we let people to stay vulnerable because nobody has a time to patch it?

It seems like a considerable risk, given the very niche nature of bind-dyndb-ldap.

It still has an upstream of it's own, which provides build-fixes. Also, patching it isn't too hard if upstream is slow, here are some examples:

https://pagure.io/bind-dyndb-ldap/c/5dd2fefa0bc7cd7689004cec64304c3a02be9eab?branch=master https://pagure.io/bind-dyndb-ldap/c/f435a334fe64585557e17adccbdfe8fd5b19d097?branch=master

and if need be, I'd still be able to help there