Re: Bug#1132159: zlib1g-udeb has new depends (lib32z1)

--nskwf6lg7duli4tg
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Roland,

Thanks for spotting and filing this.

Roland Clobus <[email protected]> (2026-03-28):
> Hello maintainers of zlib,
>=20
> 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]
>=20
> 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`
>=20
> 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=20
    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=
=2E1.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=
=2E1 -> 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=20
    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=
=2E1.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=
=2E1 -> 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 (>=3D 1:1.2.3.3.dfsg-1), libc6-udeb (>=3D 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$ objdum=
p -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$ objdum=
p -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
=E2=80=9Clibz 1=E2=80=9D entries:

    (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ cat de=
bian/lib32z1/DEBIAN/shlibs=20
    libz 1 lib32z1 (>=3D 1:1.2.3.3.dfsg-1)

    (unstable-amd64-devel)kibi@tokyo:/tmp/zlib-1.3.dfsg+really1.3.2$ cat de=
bian/zlib1g/DEBIAN/shlibs=20
    libz 1 zlib1g (>=3D 1:1.2.3.3.dfsg-1)
    udeb: libz 1 zlib1g-udeb (>=3D 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,
--=20
Cyril Brulebois ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

--nskwf6lg7duli4tg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmnIAzIACgkQ/5FK8MKz
VSDtixAAjxFgDkR/8sLB/Z/NlJkF2pT+mr2o66kU36QN4s4K4NSvT4q68gpCMnYy
5qBq/Qte+gF40RS4zPUTmhKTLUP1p1HEaoiplbkhWlJnwhcmQz/rEhwKiMNhUXwt
omC3/SREMCfTigRuc7Aqo0nqFBJx2cclVdbMYKF2Sj4nxiw151uYehSTtaTUbNvB
WUiTXM3y7ivIzT+eBPoa1bbWJISfhg+1ljRnyOM9vG7L1PlNd3RGrXtUhVZzHntJ
87XPQui9swWnrUqkr66m8pAfnv2suRr+ga0r64UCisu/FGHS6JCkOVEfFqsSsR93
E8KOVq4kWMJsLlSqzee2bOu8YB9BkCldP3KrSz8I3fTrEqVXgZpX1bKn5h8nXjsY
GgF8gtuzhQW5ET66PSn4uSFOysU74aK9z9Ni492GvVoerIlWse/YaBMZbTaVeab5
aDJ6ibUmIyerTOL+MALpGKCJgdP3JP38Kc5iCCV0wXZhG+p5yroWSTkagdDzX+Rz
HQXxuiZ5zSz5K5pYPxKFAn2yEWEco1gvQHcOY+zzzvJ2vrOEyYgAbsAxyYXHLRE7
PVq3mtNwj3gT94OWV1+BONozoBvFWV8BsNOi+IhoQPFGY4Dxtu391WdBCkMlT6wz
FTBIslJG6x1WahKMaCivSXHP+lP1cFKTGcQ2a1/XjAqkCcF0sVs=
=sZJ3
-----END PGP SIGNATURE-----

--nskwf6lg7duli4tg--