Am 02.08.2013 14:14, schrieb Bartłomiej Piotrowski:
On 2013-08-02 08:41, Pierre Schmitz wrote:
But more important please don't add random third party patches/modules and keep the package vanilla. There are good reasons we have the "don't patch" policy. They can break on nginx updates, introduce new issues etc.; esp. since they are built-in. There might be very good reasons why these modules are not included in the upstream distribution.
But the main point is to create separate nginx package with third party modules. Now we ship nginx with Passenger module and I have to rebuild nginx every time the latter has been upgraded.
If we would create nginx-3rdparty, we could move Passenger and add other external modules by the way.
First, I have to apologize; I thought the nginx package would also have these external "modules". I missed that you build two copies in the build function. If you abuse the split package this way, you still have to rebuild and publish both split packages if e.g. the passenger module requires a rebuild. In general I am not sure if there is a sane way to package these build time modules. It would be impossible to cover all the combinations and external "modules" a user might want. Is it a good idea to provide a separate package that has all kinds of different modules built in? Probably not. And people who need certain non-standard modules are better off compiling their own package. I would probably provide a vanilla package with sensible defaults and make it easy for people to extend on that. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com