In regards to several off-lists inquiries downstream about people trying to add additional third party modules, I've gone and started seeking justification for enabling --with-compat.
Downstream in Ubuntu, I'm getting pushback in that the question of "Why do we need to enable this, what does it add?". I'm trying to find that justification for it, and the best I can find is Maxim's statements on a 2016 email/forum thread about how it actually makes dynamic module support truly work (in a nutshell). [1] Further, there's pushback about "Will package security updates and patches change the module ABI on security fixes or bug fixes?". I don't have a clear answer on this, and I had this question back when dynamic module support was introduced, but never got a clear answer on this point. It does beg consideration with regards to dynamic module support whether a simple patch applied to the same exact NGINX version will break ABI. The way we handle security patches and such downstream is we apply patches to the existing NGINX version via `quilt`, which applies the patch at build time. Whether this makes an ABI change or not I couldn't say, so I'm hunting a response from you, the devs, to give me a clear answer on this. So, for those who didn't read everything there's two questions here: (A) Other than making dynamic module support "work better", what does --with-compat actually do behind the scenes (In a nutshell)? (B) Will a simple patch that patches security issues or adds fixes to something later on but doesn't change the core NGINX version numbering change the module ABI in such a way that it'll break modules built against nginx without that patch (assuming that --with-compat was added, since it's apparently needed to make dynamic modules 'actually work') Thomas
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
