On 3/6/19 12:30 AM, Daniel Kahn Gillmor wrote: > 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. 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.
signature.asc
Description: OpenPGP digital signature
-- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
