Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
Hi, On 28-07-2022 12:27, Bernhard Turmann wrote: 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? bind-dyndb-ldap needs to be binNMUed in stable too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
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
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
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ý (He/Him) > On 7. 7. 2022, at 10:51, Paul Gevers wrote: > > Hi, > >> On 07-07-2022 10:14, Ondřej Surý wrote: >> As a immediate remedy, I can do the babysitting with each bind9 release. > > 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 OpenPGP_signature Description: Binary data
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
Hi, On 07-07-2022 10:14, Ondřej Surý wrote: As a immediate remedy, I can do the babysitting with each bind9 release. 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
As a immediate remedy, I can do the babysitting with each bind9 release. Ondrej -- Ondřej Surý (He/Him) > On 7. 7. 2022, at 10:03, Ondřej Surý wrote: > > 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ý (He/Him) > >> On 7. 7. 2022, at 9:30, Paul Gevers 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 >>
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
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ý (He/Him) > On 7. 7. 2022, at 9:30, Paul Gevers 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 >
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
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
