Hello! On Thu, May 10, 2018 at 01:17:41PM +0300, Ruslan Ermilov wrote:
> 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. While compatibily with nginx-plus is indeed provided by --with-compat as well, I doubt that this aspect is interesting to Thomas. More importantly, "--with-compat" provides compatibility between builds with different configure options. Without the "--with-compat" argument, one have to use exactly the same "./configure" line to build both nginx and a module. The "--with-compat" option relaxes this restriction, and it is more or less enough to build both nginx and a module with "--with-compat". This generally simplifies building dynamic modules, and also allows one to load the same module into different nginx variants built with different flags. > > (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. While it is unlikely, it is possible. Care should be taken when applying patches without changing the version number. Whether "--with-compat" is specified or not is irrelevant. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
