Is there a particular reason --with-compat isn't enabled by default?

[Ruslan Ermilov]

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.