Re: How to handle nginx 3rd party modules?
On Tue, Mar 09, 2021 at 10:29:53AM -0500, Felix Kaechele via devel wrote: ... [snip great email] ... > So I'd appreciate some input here as to what the best way forward would be > from a distribution engineering perspective. Hi Felix, that's a fantastic write up! I think you have outlined the different options, the complexity and trade-offs involved there extremely well, that matches exactly how I see it. One thing I'd add - even for something as "simple" as the lua module, the OpenResty folks seem to not recommend it's used with upstream nginx, instead they recommend what is basically their own fork of nginx: https://github.com/openresty/lua-nginx-module#installation Hence it's never been obvious to me that if you start down this road, it you can easily stop. If you worked out how to ship the lua module, the next bug report will be that you need to adopt a handful of the OpenResty patches for nginx as well to make the lua module work properly. And then you end up packaging "OpenResty" rather than "nginx"? For RHEL we have maintained a hard line on your (4) - just don't do it. We ship "nginx", and that's it. Until NGINX upstream wants to support an external API/ABI and externally built third-party modules, we should not try to do it ourselves. (Apache httpd has supported this model for *over two decades*. It's not like it is rocket science, nor can it be unclear there is is some demand for this.) I think your option (1) - bundle some extra modules directly in the nginx SRPM - would be absolutely fine for Fedora *if* those maintaining that package have the time & effort to maintaining that. I'm afraid I'm not going to volunteer any time for that though :( Regards, Joe [Manager for team which owns RHEL HTTP servers, inter alia] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How to handle nginx 3rd party modules?
Fedorans, I am the maintainer of the nginx package in Fedora and EPEL. Currently I have two bug reports [1][2] open against nginx that ask for the inclusion of 3rd party extensions into the nginx main package. Unlike the Apache httpd, the nginx codebase does not allow modules to be built out-of-tree. This means that any and all modules you would want to use with nginx would have to be built against the same source tree using the same configure arguments used to build the main nginx package In fact, ideally together with the main nginx package. This means introducing external codebases into the nginx build tree. A few options as to how this could be addressed: 1. Bundle and ship the 3rd party modules in the main nginx package. Debian does this [3]. Debian also has a team of maintainers for nginx. In Fedora it is mainly me at this point. It increases the burden to package nginx because now I also need to track updates, CVEs and patches for these submodules and ensure they build against whichever update we are packaging at any given time. As I don't use any additional modules on my nginx installs I would not be willing to test each and every module additionally to the main package. 2. Offer a module of the main package that includes all the modules people may want. This is essentially duplicating the effort of packaging nginx but this way it wouldn't interfere with the main package too much. Also, this means someone else could take care of it. The question would then be: Do we do this for both the stable and mainline branch? 3. Use the packaging method used in this [4] COPR The method used here is simply to duplicate the building of nginx into each module separately and at the end of the build process only fish out the module file itself, plus any configuration and docs provided by the module. This option is elegant in that it generates separate packages and can be maintained in separate spec files but it requires all modules to be rebuilt or updated together with any new nginx package that is built as the modules would need to depend on the nginx package's NEVRA. This would make updating nginx quite the pain, I assume. 4. Not do it at all. As a compromise I could look to amend the current spec file to make it obvious how to build additional modules into your own version of the package. Anyone would then be free to maintain their own personal repository (possibly on COPR) to override the official packages. So I'd appreciate some input here as to what the best way forward would be from a distribution engineering perspective. Regards, Felix [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1654698 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1768317 [3]: https://salsa.debian.org/nginx-team/nginx/-/tree/master/debian/modules [4]: https://copr.fedorainfracloud.org/coprs/mtorromeo/nginx-modules-el7/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
