Comment 10 for bug 1978849

Summary:

# focal

focal's src:bind-dyndb-ldap situation is more complicated, a simple rebuild won't fix it. In focal we have two bind9 sources: src:bind9-libs, and src:bind9, at very different versions. Focal's bind-dyndb-ldap does not work with the version of src:bind9 shipped there, hence src:bind9-libs being available at a lower version. This allows src:bind-dyndb-ldap to build, but it doesn't load correctly into bind9's server at runtime. I don't even know if it can be made to work. TBD

# jammy and later

A simple rebuild fixes it. I checked if we can relax the bind9-libs dependency, but even if we could, it won't help: src:bind9 in jammy and later produces very specific libraries, with the full ubuntu version in their soname:

$ objdump -x /lib/x86_64-linux-gnu/libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so | grep SONAME
  SONAME libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so

So even a simple no-change rebuild of src:bind9 in these releases will change the soname, and will require a src:bind-dyndb-ldap rebuild to link with the new one.

The plan for jammy and later, therefore, is to add a dep8 test to these packages (src:bind-dyndb-ldap and src:bind9) which will load the ldap.so module into bind. This will block a src:bind9 update without an accompaining src:bind-dyndb-ldap update, because the test will fail without a rebuild.

This is a bit awkward: a package in universe can now block the release of a critical package like bind9 (if the test fails). If we ever get into a situation where a bind9-dyndb-ldap bug (where just a rebuild is not enough to get the test to pass) blocks a critical bind9 update, we will have to override the test.