<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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]</p>
<p>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.</p>
<p>So, for those who didn't read everything there's two questions
here:</p>
<p> (A) Other than making dynamic module support "work better", what
does --with-compat actually do behind the scenes (In a nutshell)?</p>
<p> (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')</p>
<p><br>
</p>
<p>Thomas</p>
</body>
</html>