Our intention is to to build nginx with pcre3. However, nginx by default
prefers pcre2. As a result, when libpcre2-dev is installed, nginx will
be built with pcre2, which is not intended.
Furthermore, users of nginx-dev will also meet test failures when they
try to compile module related to pcre because of this. To reproduce,
simply:
```
apt-get install nginx-dev devscripts libpcre2-dev
apt-get source libnginx-mod-http-subs-filter
cd libnginx-mod-http-subs-filter-*/ && debuild -us -uc
```
Nginx does not officially provide a mechanism to build out-of-tree modules,
however, this can be achieved by using all the headers and the configure
scripts in the auto/ directory. As a result, a nginx-dev package can thus be
developed for build out-of-tree modules.
The detailed steps to build an out-of-tree module in the headers-only nginx
source tree is:
1. Execute the configure script of nginx, with the same configure arguments
(excluding the reference to other dynamic modules, but including the reference
to depending modules as a built-in module). To prevent the configure scripts
modifying the nginx ource tree, we can 1. point the build dir to a directory
elsewhere, to generate all the build time files outside; 2. slightly patch the
configure scripts to prevent generating a makefile directly in the source tree,
which simply includes the generated makefile at the build dir.
2. Execute make at the source tree, but providing the generated makefile in the
build dir. The command is `make -C /path/to/nginx/source -f
/path/to/build_dir/Makefile modules`
To make sure the compiled module is compatible with the nginx binary and the
nginx binaries with the same upstream version, the key points are:
- Module signature: A module signature containing the (upstream) version number
and encoding the necessary configuration flags is put in each module as well as
the nginx binary itself. When loading a module, nginx will compare the signature
on the module with its own. As long as the configure flags, especially those
encoded in the signature, and the version of the nginx source used to build the
module are the same as thoes used to build the nginx binary, the moudle can pass
the signature check. As a result, the module can depend on the exact nginx
upstream version, ignoring the debian revison.
- ABI compatibility: We should maintain nginx precisely, to prevent making any
ABI changes between different debian revisions.
- Build check: When building the module, we can perform a simple module loading
check via `nginx -t`. This test serves as a "smoking test", to ensure we are
actually building loadable modules.
Summing all the above up and adding the necessary automation scripts for module
packaging, the nginx-dev package can be composed, including the following parts:
- The headers and configure scripts: generated and filtered out from the source
tree. The scripts are slightly patched to prevent generating a makefile directly
in the source tree, as stated above;
- The recorded configure options: all the modules built should include these
options when configured;
- dh_nginx script and its man page: modified from the original dh_nginx script,
adding a "--in-nginx-tree" option. When specified, the behavior remains the same
as the original version (so the option is added in the rule building the
in-package modules). When not specified, the dependency added into misc:Depends
will be the exact upstream nginx version, ignoring the debian revision. E.g.
nginx-common >= 1.20.2, << 1.20.2.1~
- a debhelper sequence plugin which can be enabled by module packages with `dh
--with=nginx`, inserting `dh_nginx` after `dh_install`
- a build system plugin which can bu enabled by module packages with `dh
--buildsystem=nginx_mod`, automating the module building process using the steps
mentioned before.
- autoscript templates used by dh_nginx are also installed without modification.
Currently. the architecture of nginx-dev is any because nginx has arch related
dependencies, which is brought in by http-lua module. After it is
removed from the nginx source tree, the architecture can be changed to
all since no binary is included in this package.
Since debhelper 10 systemd & autoreconf are enabled by default, we need
systemd and not autoconf so we reverse the logic.
While at it, drop not needed autotools dependency.
Using the same flags broke the build since -shared was not positioned
after pie/pic flags. Changing the perl LDDFLAGS patch and moving
Config{lddflags} to the end solved that issue.
As a general note, the injected -fPIC in debian/rules is not needed
since dpkg 1.18.13. We inject -fPIC so that it overrides previous -PIE
flag, but the latest dpkg automatically strips pie flags when building
shared libraries (man dpkg-buildflags).
We temporary keep the -fPIC injection for wheezy/jessie backports and
downstream Ubuntu builds.
Other proxy modules like FastCGI & Proxy were already enabled, but the
true reason for this change is that libnginx-http-cache-purge depends on
those modules being enable.
It makes things much easier if all our modules are installable along
with all possible nginx binaries. After all, this is transient until
we move to a single nginx-binary package that ships /usr/bin/nginx.
nginx-light is the only flavor that doesn't include SSI so we
are including it there.
Also, we switch the nginx-light module test to use
libnginx-mod-http-perl, that way it's more likely to fail.
