Hi Roland, Thanks for spotting and filing this.
Roland Clobus <[email protected]> (2026-03-28): > Hello maintainers of zlib, > > The udeb has picked up a new dependency on lib32z1, which was not present in > the previous version. This missing dependency makes the Debian installer > FTBFS, > see [1] > > I've looked at the difference in debian/control, and the only difference there > is the line `X-DH-Compat: 14`, which does not match the debian/changelog entry > `Bump debhelper compat to 15` > > Would it need a udeb package for lib32z1 or is the new dependency > unintentional? Let's look at the current list of binary packages: zlib1g zlib1g-dev zlib1g-udeb lib32z1 lib32z1-dev minizip libminizip1t64 libminizip-dev Let's look at the contents over time: (unstable-amd64-devel)kibi@tokyo:/tmp$ dpkg --contents zlib1g-udeb_1.2.13.dfsg-1_amd64.udeb drwxr-xr-x root/root 0 2022-11-05 13:24 ./ drwxr-xr-x root/root 0 2022-11-05 13:24 ./lib/ drwxr-xr-x root/root 0 2022-11-05 13:24 ./usr/ drwxr-xr-x root/root 0 2022-11-05 13:24 ./usr/lib/ -rw-r--r-- root/root 121152 2022-11-05 13:24 ./usr/lib/libz.so.1.2.13 lrwxrwxrwx root/root 0 2022-11-05 13:24 ./usr/lib/libz.so.1 -> libz.so.1.2.13 In this version, we have extra contents within the package, avoiding the need for an extra udeb (no minizip-specific udeb, everything shipped within the existing udeb): (unstable-amd64-devel)kibi@tokyo:/tmp$ dpkg --contents zlib1g-udeb_1.3.dfsg+really1.3.1-3_amd64.udeb drwxr-xr-x root/root 0 2026-02-16 15:40 ./ drwxr-xr-x root/root 0 2026-02-16 15:40 ./lib/ drwxr-xr-x root/root 0 2026-02-16 15:40 ./usr/ drwxr-xr-x root/root 0 2026-02-16 15:40 ./usr/lib/ -rw-r--r-- root/root 51448 2026-02-16 15:40 ./usr/lib/libminizip.so.1.0.0 -rw-r--r-- root/root 125248 2026-02-16 15:40 ./usr/lib/libz.so.1.3.1 lrwxrwxrwx root/root 0 2026-02-16 15:40 ./usr/lib/libminizip.so.1 -> libminizip.so.1.0.0 lrwxrwxrwx root/root 0 2026-02-16 15:40 ./usr/lib/libz.so.1 -> libz.so.1.3.1 There's also no specific dependency there. In this version, we have similar contents: (unstable-amd64-devel)kibi@tokyo:/tmp$ dpkg --contents zlib1g-udeb_1.3.dfsg+really1.3.2-1_amd64.udeb drwxr-xr-x root/root 0 2026-03-24 02:05 ./ drwxr-xr-x root/root 0 2026-03-24 02:05 ./usr/ drwxr-xr-x root/root 0 2026-03-24 02:05 ./usr/lib/ -rw-r--r-- root/root 59792 2026-03-24 02:05 ./usr/lib/libminizip.so.1.0.0 -rw-r--r-- root/root 121200 2026-03-24 02:05 ./usr/lib/libz.so.1.3.2 lrwxrwxrwx root/root 0 2026-03-24 02:05 ./usr/lib/libminizip.so.1 -> libminizip.so.1.0.0 lrwxrwxrwx root/root 0 2026-03-24 02:05 ./usr/lib/libz.so.1 -> libz.so.1.3.2 but we do have dependencies, possibly because of the compatibility bump: Depends: lib32z1 (>= 1:1.2.3.3.dfsg-1), libc6-udeb (>= 2.42) Let's look at the dependencies at the ELF level: (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ objdump -x debian/zlib1g-udeb/usr/lib/libminizip.so.1.0.0|grep NEEDED NEEDED libz.so.1 NEEDED libc.so.6 (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ objdump -x debian/zlib1g-udeb/usr/lib/libz.so.1.3.2|grep NEEDED NEEDED libc.so.6 I think there might be some confusion going on because of the duality of “libz 1” entries: (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ cat debian/lib32z1/DEBIAN/shlibs libz 1 lib32z1 (>= 1:1.2.3.3.dfsg-1) (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ cat debian/zlib1g/DEBIAN/shlibs libz 1 zlib1g (>= 1:1.2.3.3.dfsg-1) udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg-1) I suppose the first one gets picked up (which is arch-specific, and doesn't feature a udeb line) instead of the second one (which is generic and is desired in this case). I'm not sure how to best solve this. Cheers, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
