On Wed, May 09, 2018 at 12:29:06PM -0400, Thomas Ward wrote: > 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)?
It enables some macros and alters some structures in a way that's compatible with NGINX Plus, built with the same option. Practically this means that checksums of module loadable objects will be identical between when using F/OSS sources and when using NGINX Plus sources. Searching for "NGX_COMPAT" throughout the F/OSS source code will give enough details. > (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') If a patch is simple, this is highly unlikely. For a patch to break the ABI, at least some externally visible structures should be changed in some backwards incompatible ways. _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
