#1014503 bind9-libs: please provide libraries that enable reverse dependencies to use them

Package:
bind9-libs
Source:
bind9
Description:
Shared Libraries used by BIND 9
Submitter:
Paul Gevers
Date:
2024-10-10 09:03:02 UTC
Severity:
serious
Tags:
#1014503#5
Date:
2022-07-07 07:26:02 UTC
From:
To:
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
#1014503#12
Date:
2022-07-07 08:00:36 UTC
From:
To:
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ý <ondrej@sury.org> (He/Him)
#1014503#17
Date:
2022-07-07 08:14:13 UTC
From:
To:
As a immediate remedy, I can do the babysitting with each bind9 release.

Ondrej
--
Ondřej Surý <ondrej@sury.org> (He/Him)
#1014503#22
Date:
2022-07-07 08:49:32 UTC
From:
To:
Hi,

If you can *actively* ping the Release Team to do the binNMU'ing, I
think that's fine for now. It's just that we don't have tooling to
detect this automatically. (That could miss binNMU's for bind9 to go
undetected for a while, but maybe as the maintainer you are most of the
time aware of those too)

Paul
#1014503#27
Date:
2022-07-08 16:55:37 UTC
From:
To:
Ok, that should work if it doesn’t bother you much.

Also generally speaking, the upstream has 3rd Wednesday in a month release schedule. Obviously, there are exceptions, but we try to adhere to the schedule and it works ok for everyone. I tried to bring transparency and predictability to the BIND 9 development. Others will need to judge me if I succeeded.

Ondřej
--
Ondřej Surý <ondrej@sury.org> (He/Him)
#1014503#32
Date:
2022-07-28 10:27:49 UTC
From:
To:
Paul, Ondřej,
you mentioned bug 1004729 which is marked as done. That might be indeed
the case for unstable/testing.

Unfortunately, this is not the case for the version
bind-dyndb-ldap/11.6-3 in bullseye stable after several newer bind9
releases merged into stable with 9.16.27 being the latest.

Means, currently, bind-dyndb-ldap is broken in stable. What is the
correct way to get this resolved and maintain it like that?

For now, I use apt mark of older bind9 9.16.15 as an emergency
workaround until a solution is found.

Thanks
Berni
#1014503#37
Date:
2022-07-28 10:57:36 UTC
From:
To:
Hi,

bind-dyndb-ldap needs to be binNMUed in stable too.

Paul