Ahoy,
I have observed the following discrepancy on Trixie and it appears to affect unstable in the same way. This bug report is sort of a story format to inform aspiring bug hunters and leave little doubt about the nature of my concerns.
The libidn2.a static library contains object files from libunistring. These can be extracted into a current working directory by doing
$ ar -t /usr/lib/x86_64-linux-gnu/libidn2.a | grep -E '^libunistring' | xargs -E '' -- ar -x /usr/lib/x86_64-linux-gnu/libidn2.a
which yields
$ ar -t /usr/lib/x86_64-linux-gnu/libidn2.a | grep -E '^libunistring' | xargs -E '' -L 1 -- ar -x /usr/lib/x86_64-linux-gnu/libunistring.a
From comparing them, I can see that some object files are bit-for-bit identical but most aren't:
$ for object in libidn2-extract/*.o; do cmp "$object" libunistring-extract/"${object##*/}" 2>/dev/null && printf '%s matches\n' "${object##*/}"; done
At first I conjectured that this is because the libidn2 version that ended up in Trixie (2.3.8-2) was uploaded about one week before Trixie's libunistring version (1.3-2) was [1] [2], and so the binaries would be very similar but not identical. This would be a license violation, because the libidn2-dev binary package would carry object files from libunistring-dev 1.3-1 which is no longer in the Debian archive in source form [3]. This is the sort of thing Built-Using is intended to prevent. Just to double-check my theory, I got the old binary package from snapshot.debian.org [4]... but I couldn't believe this wasn't it!
$ curl -L -O https://snapshot.debian.org/file/6362f906874dd02c4c724bc9433a1b16bccd2d80/libunistring-dev_1.3-1_amd64.deb
$ dpkg-deb -x ./libunistring-dev_1.3-1_amd64.deb ./libunistring-dev_1.3-1/
$ mkdir libunistring-extract_1.3-1/
$ cd libunistring-extract_1.3-1/
$ ar -t /usr/lib/x86_64-linux-gnu/libidn2.a | grep -E '^libunistring' | xargs -E '' -L 1 -- ar -x ../libunistring-dev_1.3-1/usr/lib/x86_64-linux-gnu/libunistring.a
"Where else could these object files be coming from?" I asked. The answer lies in the build log [5]:
and the refreshed copy of embedded libunistring later gets built and used, even though it's not supposed to [6] (unimportant compiler hardening and warning options omitted for brevity):
$ DEBUGINFOD_URLS=${DEBUGINFOD_URLS:-"https://debuginfod.debian.net https://debuginfod.elfutils.org"} eu-srcfiles -e /usr/lib/x86_64-linux-gnu/libidn2.so | grep -F unistr
The gcc invocations in the build logs don't show the -isystem option being used, as is sometimes done in cases like this, but just -I. Therefore I'm inclined to believe those last few headers really are obtained from the system's true libunistring in preference to the headers in the build directory. What a horrible mess.
Now, the build log has messages such as
It's not apparent why an included libunistring (from any origin) is being used. This is probably a bug in Gnulib, autotools, or some other far-out place. Maybe the responsible Gnulib modules can be disabled, but otherwise I think setting Built-Using on gnulib is necessary for license compliance here as this libunistring is still GNU LGPL just the same. Let me know if you'd like me to elaborate on how it's a license conformance problem and why the GNU LGPL confers that obligation here. I recently gave some advice about this in opening bug #1143501 which you may like to peek at.
I'm going to get some sleep now. Hopefully this mail is at least mildly comprehensible, and it doesn't put you to sleep just the same
P.S. gnulib-tool has features to export machine-readable information about the licenses of used modules and give special care for the GNU (L)GPL, and the debhelper module could be made smart enough to hook into dh_builtusing to set that field when a relevant module gets pulled in or used. Otherwise this seems like a "gotcha" that could bite other packages. That'd be a great long-term solution.
[1] https://lists.debian.org/msgid-search/E1ttE7I-003r29-PP%40fasolo.debian.org
[2] https://lists.debian.org/msgid-search/E1twCKg-008V3v-HH%40fasolo.debian.org
[3] https://deb.debian.org/debian/pool/main/libu/libunistring/
[4] https://snapshot.debian.org/file/6362f906874dd02c4c724bc9433a1b16bccd2d80/libunistring-dev_1.3-1_amd64.deb
[5] https://buildd.debian.org/status/fetch.php?pkg=libidn2&arch=amd64&ver=2.3.8-2&stamp=1741995249&raw=1#line=1944,1952
[6] https://buildd.debian.org/status/fetch.php?pkg=libidn2&arch=amd64&ver=2.3.8-2&stamp=1741995249&raw=1#line=4131,4167