On Tue 2019-03-05 21:32:18 +0100, Vladimír Čunát 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? 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

On Wed 2019-03-06 09:03:28 +0100, Vladimír Čunát 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