Hi Guillem,

as just discussed in #debian-bootstrap there is a problem reproducing
the uhd package:

https://reproduce.debian.net/arm64/api/v1/builds/252324/artifacts/629453/diffoscope
https://reproduce.debian.net/amd64/api/v1/builds/277668/artifacts/739185/diffoscope

To me it looks like dpkg-shlibdeps sometimes misses the libuhd4.9.0
dependency even though it should be there as dpdk_port_test in the
package depends on it and there is no other diff.

Thanks for looking into it!

Jochen

Hi!

So, after looking into it the problem seems to be that debian/rules
specifies the following override for dh_shlibdeps:

,---
override_dh_shlibdeps:
	dh_shlibdeps --package=uhd-host --libpackage=libuhd4.9.0
	dh_shlibdeps --package=libuhd4.9.0 --libpackage=libuhd4.8.0
	dh_shlibdeps --package=libuhd4.9.0-dpdk --libpackage=libuhd4.8.0-dpdk
	dh_shlibdeps --package=libuhd4.9.0-dpdk-tests --libpackage=libuhd4.8.0-dpdk
	dh_shlibdeps --package=libuhd-dev --libpackage=libuhd4.9.0
	dh_shlibdeps --package=python3-uhd --libpackage=libuhd4.9.0
`---

Where the --libpackage is in a few cases referring to 4.8.0 instead of
4.9.0, which means that dpkg-shlibdeps gets passed a non-existent
directory in -S, and cannot prefer that package for the libuhd shared
library. And because both libuhd4.9.0 and libuhd4.9.0-dpdk provide the
same shared library with the same SONAME as different flavors, then
dpkg-shlibdeps ends up picking either one randomly depending on Perl's
hash key seed.

I've now locally added warnings to the various dpkg-shlibdeps options
taking directories on non-existent ones, so that this kind of problem
becomes more obvious in the future. (And might even consider turning
them into errors at some point probably.)

Thanks,
Guillem