5 Bře
2019
5 Bře
'19
21:32
Hello, Knot * users!
Please note that Knot DNS 2.8.x breaks all Knot Resolver versions
released so far (<=3.2.1). The breakage is a bit subtle, and build
system won't detect it.
We plan to release an update soon. If you don't want to wait, you can
apply a simple patch:
https://gitlab.labs.nic.cz/knot/knot-resolver/commit/186f2639
--Vladimir
6 Bře
6 Bře
0:30
New subject: Knot DNS 2.8.0 release
On Tue 2019-03-05 21:32:18 +0100, Vladimír Čunát wrote:
Please note that Knot DNS 2.8.x breaks all Knot
Resolver versions
released so far (<=3.2.1). The breakage is a bit subtle, and build
system won't detect it.
oof, this is definitely a subtle ABI breakage -- it looks like the lua
zs_scanner struct changed shape/size!
Fortunately, the SONAMEs in Knot DNS changed, so knot-resolver shouldn't
break based on a simple upgrade. right? Or are the lua bindings going
to ignore SONAMEs somehow?
We plan to release an update soon. If you don't
want to wait, you can
apply a simple patch:
https://gitlab.labs.nic.cz/knot/knot-resolver/commit/186f2639
This is an update to knot-resolver -- but it seems like the fix is in
kind of the wrong place. Shouldn't the the zs_scanner struct lua
definition live in the knot-dns package, so that it can be upgraded
concurrently?
Thanks for highlighting this change! I need to think about how we best
avoid this kind of breakage during sequenced upgrades in debian, so
any pointers to details about how lua and SONAMEs and struct definitions
interact would be most welcome.
At the moment, i'm just aiming to keep older versions of knot-resolver
from building against knot-dns 2.8.0 like so:
https://salsa.debian.org/dns-team/knot-resolver/commit/5709b37c29ce88c19fb0…
(which will of course change if i backport the proposed patch in
question)
Any thoughts about better ways to do that?
All the best,
--dkg
9:03
New subject: Knot DNS 2.8.0 release
On 3/6/19 12:30 AM, Daniel Kahn Gillmor wrote:
For future, I was (personally) considering the resolver build system
enforcing also maximum SONAME version, updated by hand after we verify
compatibility.
I haven't thought about moving lua bindings to the knot libraries. I
just gave it a quick thought now, but I'm afraid it wouldn't help due to
the binding APIs possibly changing faster than knot's and being too
tightly coupled with resolver.
oof, this is definitely a subtle ABI breakage -- it
looks like the lua
zs_scanner struct changed shape/size!
Fortunately, the SONAMEs in Knot DNS changed, so knot-resolver shouldn't
break based on a simple upgrade. right? Or are the lua bindings going
to ignore SONAMEs somehow?
The SONAME loaded by the affected zonefile.lua is compiled-in during
build, so you would have to rebuild against >= 2.8.0 to get into trouble.
We plan to
release an update soon. If you don't want to wait, you can
apply a simple patch:
https://gitlab.labs.nic.cz/knot/knot-resolver/commit/186f2639
This is an update to
knot-resolver -- but it seems like the fix is in
kind of the wrong place. Shouldn't the the zs_scanner struct lua
definition live in the knot-dns package, so that it can be upgraded
concurrently?
Thanks for highlighting this change! I need to think about how we best
avoid this kind of breakage during sequenced upgrades in debian, so
any pointers to details about how lua and SONAMEs and struct definitions
interact would be most welcome. At the moment, i'm just aiming to keep older
versions of knot-resolver
from building against knot-dns 2.8.0 like so:
https://salsa.debian.org/dns-team/knot-resolver/commit/5709b37c29ce88c19fb0…
(which will of course change if i backport the proposed patch in
question)
Any thoughts about better ways to do that?
I can't see a better simple way; it seems sufficient, too. Possibly a
conflict; I'm not sure if you'd be allowed to "install" multiple
versions at once through *.deb. We find libdir via pkg-config and there
we inspect SONAME of libzscanner.so (symlink). People can get burned by
locations like /usr/local anyway, which is why I thought about
build-system checks.
8 Bře
8 Bře
15:47
New subject: Knot DNS 2.8.0 release
On Wed 2019-03-06 09:03:28 +0100, Vladimír Čunát wrote:
On 3/6/19 12:30 AM, Daniel Kahn Gillmor wrote:
OK, this change is now in debian unstable as of 3.2.1-2. I might have
to ask for a freeze exception to make sure that it gets into buster, so
that we're not distributing a package in a stable release that will
break if re-built against a backported libknot, but i'll keep an eye on
it and do what's needed.
--dkg
https://salsa.debian.org/dns-team/knot-resolver/commit/5709b37c29ce88c19fb0…
Any thoughts about better ways to do that?
I can't see a better simple way; it seems sufficient, too. Possibly a
conflict; I'm not sure if you'd be allowed to "install" multiple
versions at once through *.deb. We find libdir via pkg-config and there
we inspect SONAME of libzscanner.so (symlink). People can get burned by
locations like /usr/local anyway, which is why I thought about
build-system checks.
1883
days inactive
1886
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Daniel Kahn Gillmor -
Vladimír Čunát