nginx-sid/debian/rules

220 lines
7.3 KiB
Text
Raw Permalink Normal View History

2012-05-07 22:51:42 +02:00
#!/usr/bin/make -f
export DH_VERBOSE=1
2012-05-07 22:51:42 +02:00
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
debian_cflags:=$(shell dpkg-buildflags --get CFLAGS) -fPIC $(shell dpkg-buildflags --get CPPFLAGS)
debian_ldflags:=$(shell dpkg-buildflags --get LDFLAGS) -fPIC
FLAVOURS := core light extras
2016-08-31 14:48:28 +03:00
DYN_MODS := \
http-auth-pam \
http-cache-purge \
http-dav-ext \
2016-08-31 14:48:28 +03:00
http-echo \
http-fancyindex \
http-geoip \
http-geoip2 \
2016-08-31 14:48:28 +03:00
http-headers-more-filter \
http-image-filter \
http-ndk \
http-perl \
http-subs-filter \
http-uploadprogress \
http-upstream-fair \
http-xslt-filter \
mail \
nchan \
rtmp \
stream \
stream-geoip \
stream-geoip2
2012-05-07 22:51:42 +02:00
MODULESDIR = $(CURDIR)/debian/modules
BASEDIR = $(CURDIR)
$(foreach flavour,$(FLAVOURS) src ndksrc,$(eval BUILDDIR_$(flavour) = $(CURDIR)/debian/build-$(flavour)))
2012-05-07 22:51:42 +02:00
DEB_BUILD_ARCH ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
ifeq ($(DEB_BUILD_ARCH),sparc)
debian_cflags += -m32 -mcpu=ultrasparc
2012-05-07 22:51:42 +02:00
endif
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
2012-05-07 22:51:42 +02:00
endif
MODULESPATCHDIR = $(CURDIR)/debian/modules/patches
modules_with_patches := $(notdir $(wildcard $(CURDIR)/debian/modules/patches/*))
2014-02-23 13:49:09 +02:00
# configure flags
Adding nginx-dev package for tools for building out-of-tree modules 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.
2022-02-04 00:00:41 +08:00
basic_configure_flags := \
2014-02-23 13:49:09 +02:00
--prefix=/usr/share/nginx \
--conf-path=/etc/nginx/nginx.conf \
--http-log-path=/var/log/nginx/access.log \
--error-log-path=/var/log/nginx/error.log \
--lock-path=/var/lock/nginx.lock \
--pid-path=/run/nginx.pid \
--modules-path=/usr/lib/nginx/modules \
2014-02-23 13:49:09 +02:00
--http-client-body-temp-path=/var/lib/nginx/body \
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi \
--http-proxy-temp-path=/var/lib/nginx/proxy \
--http-scgi-temp-path=/var/lib/nginx/scgi \
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi \
--with-compat \
--with-debug \
2014-02-23 13:49:09 +02:00
--with-pcre-jit \
--with-http_ssl_module \
--with-http_stub_status_module \
--with-http_realip_module \
--with-http_auth_request_module \
--with-http_v2_module \
--with-http_dav_module \
2016-08-26 12:40:48 +03:00
--with-http_slice_module \
--with-threads
Adding nginx-dev package for tools for building out-of-tree modules 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.
2022-02-04 00:00:41 +08:00
common_configure_flags := \
--with-cc-opt="$(debian_cflags)" \
--with-ld-opt="$(debian_ldflags)" \
$(basic_configure_flags)
light_configure_flags := \
$(common_configure_flags) \
--with-http_gzip_static_module \
--without-http_browser_module \
--without-http_geo_module \
--without-http_limit_req_module \
--without-http_limit_conn_module \
--without-http_memcached_module \
--without-http_referer_module \
--without-http_split_clients_module \
--without-http_userid_module
core_configure_flags := \
$(common_configure_flags) \
--with-http_addition_module \
2015-04-07 08:23:38 -05:00
--with-http_gunzip_module \
--with-http_gzip_static_module \
--with-http_sub_module \
extras_configure_flags := \
$(common_configure_flags) \
--with-http_addition_module \
--with-http_flv_module \
2016-03-23 16:44:39 +02:00
--with-http_geoip_module=dynamic \
2015-04-07 08:23:38 -05:00
--with-http_gunzip_module \
--with-http_gzip_static_module \
2016-03-23 16:44:39 +02:00
--with-http_image_filter_module=dynamic \
--with-http_mp4_module \
2016-03-30 15:07:19 +03:00
--with-http_perl_module=dynamic \
--with-http_random_index_module \
--with-http_secure_link_module \
--with-http_sub_module \
2016-03-23 16:44:39 +02:00
--with-http_xslt_module=dynamic \
--with-mail=dynamic \
--with-mail_ssl_module \
2016-03-23 16:44:39 +02:00
--with-stream=dynamic \
--with-stream_geoip_module=dynamic \
--with-stream_ssl_module \
--with-stream_ssl_preread_module \
--add-dynamic-module=$(MODULESDIR)/http-headers-more-filter \
--add-dynamic-module=$(MODULESDIR)/http-auth-pam \
--add-dynamic-module=$(MODULESDIR)/http-cache-purge \
--add-dynamic-module=$(MODULESDIR)/http-dav-ext \
--add-dynamic-module=$(MODULESDIR)/http-ndk \
--add-dynamic-module=$(MODULESDIR)/http-echo \
--add-dynamic-module=$(MODULESDIR)/http-fancyindex \
--add-dynamic-module=$(MODULESDIR)/http-geoip2 \
2016-08-26 16:09:52 +03:00
--add-dynamic-module=$(MODULESDIR)/nchan \
--add-dynamic-module=$(MODULESDIR)/rtmp \
--add-dynamic-module=$(MODULESDIR)/http-uploadprogress \
--add-dynamic-module=$(MODULESDIR)/http-upstream-fair \
--add-dynamic-module=$(MODULESDIR)/http-subs-filter
%:
dh $@ --without autoreconf
override_dh_auto_configure: config_patch_modules $(foreach flavour,$(FLAVOURS),config.arch.$(flavour)) config.src config.ndksrc
override_dh_auto_build: $(foreach flavour,$(FLAVOURS),build.arch.$(flavour)) build.src build.ndksrc
override_dh_strip: $(foreach flavour,$(FLAVOURS),strip.arch.$(flavour)) $(foreach mod,$(DYN_MODS),strip.mods.$(mod))
override_dh_clean: clean_patch_modules $(foreach flavour,$(FLAVOURS),clean.$(flavour)) clean.src clean.ndksrc
dh_clean
override_dh_install:
dh_install
DH_AUTOSCRIPTDIR=$(CURDIR)/debian/autoscripts debian/debhelper/dh_nginx --in-nginx-tree
override_dh_installinit:
dh_installinit --no-stop-on-upgrade --no-start --name=nginx
override_dh_installsystemd:
dh_installsystemd --name=nginx
override_dh_installlogrotate:
dh_installlogrotate --package nginx-common --name=nginx
build.arch.%:
$(MAKE) -C $(BUILDDIR_$*) build
Adding nginx-dev package for tools for building out-of-tree modules 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.
2022-02-04 00:00:41 +08:00
build.src:
cp -Pa $(CURDIR)/auto $(BUILDDIR_src)/
sed -i '/^# create Makefile/,/^END$$/d' $(BUILDDIR_src)/auto/make $(BUILDDIR_src)/auto/init $(BUILDDIR_src)/auto/install
find $(CURDIR)/src -type f -name '*.h' -printf 'src/%P\0' | tar -C $(CURDIR) --null --files-from - -c | tar -C $(BUILDDIR_src)/ -x
if [ -e $(CURDIR)/configure ]; then cp $(CURDIR)/configure $(BUILDDIR_src)/; fi
echo "NGX_CONF_FLAGS=(" $(basic_configure_flags) ")" > $(BUILDDIR_src)/conf_flags
pod2man debian/debhelper/dh_nginx > $(BUILDDIR_src)/dh_nginx.1
Adding nginx-dev package for tools for building out-of-tree modules 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.
2022-02-04 00:00:41 +08:00
build.ndksrc:
cp -Pa $(CURDIR)/debian/modules/http-ndk/auto \
$(CURDIR)/debian/modules/http-ndk/config \
$(CURDIR)/debian/modules/http-ndk/ngx_auto_lib_core $(BUILDDIR_ndksrc)/
for i in src objs; do \
find $(CURDIR)/debian/modules/http-ndk/$$i -type f -name '*.h' -printf "$$i/%P\0" | \
tar -C $(CURDIR)/debian/modules/http-ndk --null --files-from - -c | tar -C $(BUILDDIR_ndksrc)/ -x; \
done
chmod +x $(CURDIR)/debian/build-ndksrc/auto/build
strip.arch.%:
dh_strip --package=nginx-$(*) -O--dbgsym-migration='nginx-$(*)-dbg (<< 1.10.1-3~)'
2014-02-23 13:49:09 +02:00
strip.mods.%:
dh_strip --package=libnginx-mod-$(*) -O--automatic-dbgsym
config_patch_modules: $(foreach mod,$(modules_with_patches),config.patch.$(mod))
config.patch.%:
cd $(MODULESDIR)/$* && QUILT_PATCHES=$(MODULESPATCHDIR)/$* quilt push -a
clean_patch_modules: $(foreach mod,$(modules_with_patches),clean.patch.$(mod))
clean.patch.%:
if [ -s $(MODULESDIR)/$*/.pc/applied-patches ]; then \
cd $(MODULESDIR)/$* && QUILT_PATCHES=$(MODULESPATCHDIR)/$* quilt pop -q -a; \
rm -rf $(MODULESDIR)/$*/.pc; \
fi
config.arch.%:
2012-05-07 22:51:42 +02:00
dh_testdir
mkdir -p $(BUILDDIR_$*)
cp -Pa $(CURDIR)/auto $(BUILDDIR_$*)/
cp -Pa $(CURDIR)/conf $(BUILDDIR_$*)/
cp -Pa $(CURDIR)/configure $(BUILDDIR_$*)/
cp -Pa $(CURDIR)/contrib $(BUILDDIR_$*)/
cp -Pa $(CURDIR)/src $(BUILDDIR_$*)/
cp -Pa $(CURDIR)/man $(BUILDDIR_$*)/
cd $(BUILDDIR_$*) && ./configure $($*_configure_flags)
if [ "$(BUILDDIR_$*)" = "$(BUILDDIR_extras)" ]; then \
have="NDK_SET_VAR"; \
/bin/echo -e "#ifndef $$have\n#define $$have 1\n#endif" >> $(BUILDDIR_$*)/objs/ngx_auto_config.h; \
fi
2012-05-07 22:51:42 +02:00
Adding nginx-dev package for tools for building out-of-tree modules 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.
2022-02-04 00:00:41 +08:00
config.src:
dh_testdir
mkdir -p $(BUILDDIR_src)
config.ndksrc:
dh_testdir
mkdir -p $(BUILDDIR_ndksrc)
clean.%:
rm -rf $(BUILDDIR_$*)
.PHONY: config_patch_modules clean_patch_modules