[arch-dev-public] Nginx
Hello, Talking about improvment on nginx package with Bartłomiej, it was suggested to push this publicly to let everyone be confident with. Nginx is a web server with modules selected (or added from external sources) at the *build* time. So we cannot package them separately and install them when needed. There is 5 kinds of modules in nginx[1]: - Core: Mandatory modules - Stardard: enabled by default - Optional: not enabled by default (like ssl module, more mandatory than optinal) - Mail: modules related to IMAP and POP proxies features - External: provided by third parties (so not shipped with upstream tarball) We currently have a mix of the 5 kinds of modules in our nginx package. Passenger is our external module[2]. When I wanted to add auth-pam external module, it was suggested to me to split the nginx package to have external modules in a dedicated package to avoid rebuilding "main" modules when 3rd party modules are updated. I started a draft version[6]. Looking around: - Fedora[3], have one package with one external module (nginx-upstream-fair)[7]. - Debian[4], have different packages, in relation with the feature enabled, not the module kind. In each package (light, full, extra) there is external modules enabled. - Opensuse[5], have one package with one external module built in (passenger too) Externals modules are not often updated (e.g: auth-pam 11/2010, upstream-fair: 4/2012). Furthermore, there is no install-time dependencies added by passenger or the previous others external. Taking this in consideration, there is probably no need to split nginx and we can have only one package and update it when it's necessary. Cheers, [1] http://wiki.nginx.org/Modules [2] https://www.archlinux.org/packages/community/x86_64/passenger/ [3] https://admin.fedoraproject.org/pkgdb/acls/name/nginx [4] http://packages.debian.org/search?keywords=nginx-&searchon=names&suite=unstable [5] https://build.opensuse.org/package/show/server:http/nginx [6] https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/nginx&id=677192 [7] Even if I doesn't find any trace of this module in build script. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Am 01.08.2013 22:59, schrieb Sébastien Luttringer:
Externals modules are not often updated (e.g: auth-pam 11/2010, upstream-fair: 4/2012). Furthermore, there is no install-time dependencies added by passenger or the previous others external.
Taking this in consideration, there is probably no need to split nginx and we can have only one package and update it when it's necessary.
The PKGBUILD looks strange, but I guess you already noticed that. The nginx-extra package is identical to the nginx package except its dependencies. Just use optdepends here if needed. 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. So in short: Don't split nor patch and keep the package as vanilla as possible. People can easily build their own if they need special "modules" or patches. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
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. -- Bartłomiej Piotrowski http://bpiotrowski.pl/
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
On 08/02/2013 02:55 PM, Pierre Schmitz wrote:
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.
I think it is a good case for keeping vanilla package in `community` and providing semi-official AUR package that allows easy selection of custom modules but is guaranteed to be the same in all other ways. Re-building does inevitable with such architecture, so it is all about making it convenient.
On Fri, Aug 2, 2013 at 2:55 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am 02.08.2013 14:14, schrieb Bartłomiej Piotrowski:
On 2013-08-02 08:41, Pierre Schmitz wrote:
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. Yep. We will drop the split package.
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? There is no perfect solution with build time modules. It's broken by design.
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. So, I think we'll rollback to one package co-maintained by Bartholomej and me, with interesting optional modules and auth-pam (I use it). Nothing should block a nginx update, so if auth-pam is incompatible, it will be dropped.
Passenger external module will be dropped as it causes too frequent rebuild. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
Am 02.08.2013 15:38, schrieb Sébastien Luttringer:
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? There is no perfect solution with build time modules. It's broken by design.
Does anybody know why the devs don't want or implemented modules than can be loaded at runtime?
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. So, I think we'll rollback to one package co-maintained by Bartholomej and me, with interesting optional modules and auth-pam (I use it). Nothing should block a nginx update, so if auth-pam is incompatible, it will be dropped.
Passenger external module will be dropped as it causes too frequent rebuild.
I'd say better drop all third-party modules even if you use it yourself. I don't see why this should be an exception on the contrary: it was not merged upstream and it was last updated in 2010. And dropping it in case of an issue also introduces unexpected regressions for those users who started using it. So my recommendation would still be to keep at least the nginx package minimal and vanilla. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
On Fri, Aug 2, 2013 at 4:59 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am 02.08.2013 15:38, schrieb Sébastien Luttringer: Does anybody know why the devs don't want or implemented modules than can be loaded at runtime? http://forum.nginx.org/read.php?2,123868,124118#msg-124118
Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 03/08/13 00:59, Pierre Schmitz wrote:
Am 02.08.2013 15:38, schrieb Sébastien Luttringer:
Nothing should block a nginx update, so if auth-pam is incompatible, it will be dropped.
Passenger external module will be dropped as it causes too frequent rebuild.
Yet the current post_upgrade message says it is still there... And if you are already envisioning that auth-pam will need to be dropped in the future, I'd have to agree with this:
I'd say better drop all third-party modules even if you use it yourself. I don't see why this should be an exception on the contrary: it was not merged upstream and it was last updated in 2010. And dropping it in case of an issue also introduces unexpected regressions for those users who started using it.
So my recommendation would still be to keep at least the nginx package minimal and vanilla.
Agreed, only provide what upstream does. The rest should be dealt with by ABS/AUR. Allan
On Fri, Aug 30, 2013 at 8:34 AM, Allan McRae <allan@archlinux.org> wrote:
On 03/08/13 00:59, Pierre Schmitz wrote:
Am 02.08.2013 15:38, schrieb Sébastien Luttringer:
Nothing should block a nginx update, so if auth-pam is incompatible, it will be dropped.
Passenger external module will be dropped as it causes too frequent rebuild.
Yet the current post_upgrade message says it is still there...
And if you are already envisioning that auth-pam will need to be dropped in the future, I'd have to agree with this:
I'd say better drop all third-party modules even if you use it yourself. I don't see why this should be an exception on the contrary: it was not merged upstream and it was last updated in 2010. And dropping it in case of an issue also introduces unexpected regressions for those users who started using it.
So my recommendation would still be to keep at least the nginx package minimal and vanilla.
Agreed, only provide what upstream does. The rest should be dealt with by ABS/AUR.
Allan
I will follow the elders. I removed nginx-extra and nginx package in testing is now purely vanilla modules. Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
participants (5)
-
Allan McRae
-
Bartłomiej Piotrowski
-
Dicebot
-
Pierre Schmitz
-
Sébastien Luttringer