How to handle nginx 3rd party modules?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux