Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 573710 - www-servers/nginx - Add support for external 3rd party modules
Summary: www-servers/nginx - Add support for external 3rd party modules
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Thomas Deutschmann
Depends on:
Blocks: 648334
  Show dependency tree
Reported: 2016-02-02 21:32 UTC by Daniel Hiepler
Modified: 2021-01-13 14:33 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---

external ngx-devel-kit livebuild (ngx-devel-kit-9999.ebuild,865 bytes, text/plain)
2016-02-02 21:32 UTC, Daniel Hiepler
ngx-http-form-input livebuild (ngx-http-form-input-9999.ebuild,1.00 KB, text/plain)
2016-02-02 21:33 UTC, Daniel Hiepler
ngx-http-set-misc livebuild (ngx-http-set-misc-9999.ebuild,979 bytes, text/plain)
2016-02-02 21:33 UTC, Daniel Hiepler
external ngx-devel-kit livebuild (ngx-devel-kit-9999.ebuild,848 bytes, text/plain)
2016-02-03 17:46 UTC, Daniel Hiepler
ngx-http-form-input livebuild (ngx-http-form-input-9999.ebuild,1004 bytes, text/plain)
2016-02-03 17:47 UTC, Daniel Hiepler
ngx-http-set-misc livebuild (ngx-http-set-misc-9999.ebuild,959 bytes, text/plain)
2016-02-03 17:48 UTC, Daniel Hiepler

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Hiepler 2016-02-02 21:32:34 UTC
Created attachment 424504 [details]
external ngx-devel-kit livebuild

So I don't have to touch the official nginx.ebuild on every update, I wrote separate (live) ebuilds for the modules I need (s. attachment).

Those ebuilds install the modules' sources to /usr/src and install a file into /etc/env.d/ with the form:


Because I can't explicitly avtivate ngx-devel-kit, I made an ebuild for that aswell.

The only disadvantage i see right now is, that nginx won't be rebuilt if a module is updated. An ewarn mentions this.

If you like, you could conditionally depend on those modules by USE-flag to overcome the updating issue and to enable users, to select modules implicitly by changing USE-flags.
Then, NGINX_ADD_MODULES should probably changed to something like NGINX_UNMAINTAINED_MODULES ...
Comment 1 Daniel Hiepler 2016-02-02 21:33:13 UTC
Created attachment 424506 [details]
ngx-http-form-input livebuild
Comment 2 Daniel Hiepler 2016-02-02 21:33:48 UTC
Created attachment 424508 [details]
ngx-http-set-misc livebuild
Comment 3 Daniel Hiepler 2016-02-03 17:46:51 UTC
Created attachment 424568 [details]
external ngx-devel-kit livebuild

- Fixed bug, so ngx-devel-kit is always at the beginning of the NGINX_ADD_MODULES envvar.
- Fixed \n not interpreted by echo.
- Removed stale $NGINX_ADD_MODULES
Comment 4 Daniel Hiepler 2016-02-03 17:47:39 UTC
Created attachment 424570 [details]
ngx-http-form-input livebuild

- Removed stale $NGINX_ADD_MODULES
Comment 5 Daniel Hiepler 2016-02-03 17:48:02 UTC
Created attachment 424572 [details]
ngx-http-set-misc livebuild

- Removed stale $NGINX_ADD_MODULES
Comment 6 Johan Bergström 2016-02-09 11:41:49 UTC
Thanks for your contribution! I'll have a think about your approach and get back to you with comments.
Comment 7 Thomas Deutschmann gentoo-dev Security 2016-02-10 13:58:12 UTC
Looks like upstream is also working on a solution:

I hope we will get something like PECL.
Comment 8 Johan Bergström 2016-03-02 03:26:16 UTC
So, I've thought about this for a while. The TL;DR is that we should stay off this in the 1.9.x series and see what happens with nginx 2.0 (or 1.10).

I've also spoken to the other maintainers to see if we share conclusion. Here's my rationale:

1. We've had a bit of a bad rep with the 1.6, 1.7 series where we were a bit too trigger happy with 3rd party module changes. This is avoided in the 1.8/1.9 series by only bumping (if not specific bugfixes are filed against a module) 1.9 modules. The intent is to have 1.9 brew into the next stable and then let that cool down.

2. There's not a lot of 3rd party modules that supports this just yet

3. The internal api/abi of nginx is moving pretty quick in development series. I reckon this will change with the introduction of 3rd party modules, but again; I feel we would make a premature decision by jumping on this too quickly.

With above said I think the next mainline series might be a good place to explore this.

Closing as WONTFIX for now.
Comment 9 Daniel Hiepler 2016-09-04 01:40:22 UTC
So is patching the main ebuild still the preferred method to include 3rd-party modules for 1.10.x or can we have separate ebuilds for them now, since nginx supports dynamic modules?
Comment 10 Thomas Deutschmann gentoo-dev Security 2016-09-04 10:31:01 UTC
Situation hasn't really changed: Most of our provided 3rd-party modules can't be build as dynamic module yet. And we don't have a solution yet ready for the ebuild to support something like that (will need a complete rewrite and probably an nginx eclass for the modules).

We have that on our todo list (I am re-opening this bug report to track status). But it will take some time...
Comment 11 Daniel Hiepler 2018-06-04 10:25:06 UTC
I need to get an ebuild for another 3rd party nginx module and wondered if I still need the "dirty hack" from my initial comment.

> Most of our provided 3rd-party modules can't be build as dynamic module yet.

There still are lots of those modules and I don't expect that to change in the near future. This is still the main problem I see now.
It could be resolved with epatch for every module but that would add more maintenance overhead so I'd like to avoid it. Also, I suppose some people would still like to be able to compile a module directly inside the nginx source tree, so it wouldn't be a good standard solution.

The livebuilds I attached in 2016 still work flawlessly for me (but I still need to manually re-emerge nginx after every update, which is annoying).

Are there new developments to get 3rd party modules cleanly integrated or any plans?
Comment 12 jonas.licht 2020-02-14 23:41:24 UTC
I was thinking about writing a eclass to build dynamic modules.
As I see it depends on the whole nginx source code on build time.

What do you think is a good way to get the nginx source in the eclass?
Something like the gestreamer eclass where there use the same version on all plugins.
This could mean to use a nginx version variable in the modules ebuild.
Or is there a better way?
Comment 13 jonas.licht 2020-02-14 23:48:26 UTC
(In reply to jonas.licht from comment #12)

> Or is there a better way?

Anther way is to copy the nginx src to the system.
Comment 14 jonas.licht 2021-01-13 14:33:13 UTC
I've just wrote an eclass for building dynamic nginx modules.
Together with one demo package I opened a PR: