Comment 3 for bug 2040404

teward, speaking of which, there is indeed a migration issue for nginx against one of these split out modules, libnginx-mod-http-geoip2. The issue appears to be not that the module isn't imported, but rather that nginx appears to expect its version to be equivalent to its own, but it isn't:

Package: nginx-core
Architecture: all
Depends: libnginx-mod-http-geoip2 (>= ${libnginx-mod-geoip2:Version}),
         libnginx-mod-http-geoip2 (<< ${libnginx-mod-geoip2:Version}.1~),

So nginx's autopkgtest fails:

# https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/n/nginx/20231122_220741_d4ae7@/log.gz
2440s The following packages have unmet dependencies:
2440s nginx-core : Depends: libnginx-mod-http-geoip2 (< 1:3.4-4.1~) but 1:3.4-5build1 is to be installed
2440s Depends: libnginx-mod-stream-geoip2 (< 1:3.4-4.1~) but 1:3.4-5build1 is to be installed
2440s E: Unable to correct problems, you have held broken packages.
2440s ssi-module-test FAIL badpkg

And the module also fails:

# https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/libn/libnginx-mod-http-geoip2/20231122_213148_b4894@/log.gz
:
131s
131s The following packages have unmet dependencies:
131s nginx-core : Depends: libnginx-mod-http-geoip2 (< 1:3.4-4.1~) but 1:3.4-5build1 is to be installed
131s Depends: libnginx-mod-stream-geoip2 (< 1:3.4-4.1~) but 1:3.4-5build1 is to be installed
131s E: Unable to correct problems, you have held broken packages.
131s generic FAIL badpkg

I wonder if the better approach may be to drop the versioned dependencies from nginx-core for modules that now live in their own source packages. What do you think?