Is there a particular reason --with-compat isn't enabled by default?
teward at thomas-ward.net
Wed May 9 16:29:06 UTC 2018
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). 
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')
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel