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/186f2639This 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.
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.
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/5709b37c29ce88c19fb0728cefe5a53041269225 (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.