There are several modules that are generally-useful, are loaded dynamically, and don't carry additional dependencies. Examples: CT, ECHO, DYNAMIC_UPSTREAM. Please enable some or all of these by default to ease using official packages.
Maintainer timeout, back to the pool. Nikolai, could you please provide a patch? And one for nginx-devel. If yes, also please confirm the changes pass build tests (portlint, poudriere) and a quick run test. Personally, I'm not convinced these should be added by default unless there is guarantee they will not interfere if those modules are not used. I also don't think they're so generally useful, except maybe CT, but this is just my opinion as a user commenting in the absence of maintainer opinion, and as a user wanting to run as minimally as possible required amount of software. IMHO, echo and dynamic upstreams are edge cases.
+1 on proposal. Appears to satisfy the complex (subjective) balance between user function/options in package scenarios (where customisability is limited) and the again subjective 'reasonable' dependencies measure (in this case: no increase). Port users are also not negatively impacted beyond having defaults selected for them (if that can be considered bad), which only applies to new installations (without config saved) and the level of choice remains for those users to disable functionality if so desired.
I have a rusty patch for a few versions ago. Let me catch up real quick... I would also like to investigate what it would take to have dynamic modules built as separate packages, like we do for apache.
According to our agreement with the vendor, by default we'd like to distribute "vanilla" version of the product. Follow this I see no reason to enable several third-party modules in default build.
(In reply to Sergey A. Osokin from comment #4) "Agreement with the Vendor"? Can you please elaborate? Or am I missing something about the 2-clause BSD license NGINX comes under...
I think that's just being a good netizen and distributing software the way upstream finds supportable. The way forward could be separating dynamic modules into separate packages. I'll have something available to test within the next couple of days.
Nikolai, in that case it'd be wise to file a new issue for that, perhaps even as a meta-issue for related individual ports as blocker issues, I don't know how you envisioned this. Sergey, if you don't wish to proceed with the suggestion in this PR, please feel free to close it as rejected.
Yes, please. I'm having a hard time building modules outside of nginx build itself. I'm not sure it's ideal to build nginx 10+ times to get packages for modules. What do you think about just having nginx-extra or something with non-default modules enabled and then having modules in plist?
Well, I was rather suggesting that if you want to go that route, it better have its own PR. It would, after all, be a whole new port or a set thereof. :) As for the actual approach, if the individual modules can't be made into individual ports one could install in parallel with main nginx, I'm not sure what is the best way to deal with it. We now have things like vim-lite, or <something>-nox11 that pretty much solve that packaging options problem. Perhaps nginx-extra or nginx-full, or even nginx-contrib might work. Sergey, any thoughts?
I think they can be *installed* separately, but not built outside of nginx build process. So, it's build nginx+module, discard nginx, package module for each set that would have to be separate.
Close: the new nginx-lite and nginx-full ports fill this need.