Top posting from phone. Making the bind9 libraries private was a deliberate decision by upstream, so there’s no guarantee about API/ABI between patch releases. Keeping the compatibility for isc-dhcp which is basically on life support.
bind-dyndb-ldap is kind of special because it’s the only external dyndb plug-in ever created. We’ve already talked about solutions with bind-dyndb-ldap maintainer that perhaps it should be built as part of src:bind9. Unfortunately, it’s bit of license mess because bind-dyndb-ldap is GPLv2 and BIND 9 is MPL 2 :-(. Ondřej -- Ondřej Surý <ond...@sury.org> (He/Him) > On 7. 7. 2022, at 9:30, Paul Gevers <elb...@debian.org> wrote: > > Package: bind9-libs > Version: 1:9.18.1-1 > Severity: serious > X-Debbugs-Cc: bind-dyndb-l...@packages.debian.org > Control: affects -1 bind-dyndb-ldap > > Dear bind9 maintainers, > > As a Release Manager I had to binNMU bind-dyndb-ldap already a couple > of times lately to enable src:bind9 to migrate (e.g. a recent security > update migrated only after several weeks because nobody noticed that > bind9 didn't migrate to testing). Today I had a look of why > bind-dyndb-ldap has such a tight dependency on bind9-libs and found > out that's because the libraries provided by bind9 are changing with > every build (see bug 1004729). I'm not very versed in SONAMEs and > ABI/API compatibility, but nearly all libraries are providing > soft-links to the real library file as long as the interfaces are > compatible. > > If the bind9 libraries are really not stable, i.e. they change ABI on > every build, then I think bind9 shouldn't provide public libraries. If > the libraries are for public use, like bind-dyndb-ldap uses them, than > I think you have to work out a why that bind-dyndb-ldap doesn't need > the strict dependency it has now. > > The current situation requires too much baby-sitting. Currently > binNMU'ing bind9 doesn't work without binNMU'ing bind-dyndb-ldap too > and nobody will notice that for a while. > > Paul >
