Control: reassign -1 adns [ Leaving most of the context intact for the adns maintainer. ]
Hi! On Thu, 2026-05-21 at 11:29:39 +0300, Adrian Bunk wrote: > Control: reassign -1 dpkg > Control: retitle -1 Randomness in dependencies when symbols with different > but equal versions are used > > On Thu, May 21, 2026 at 09:40:49AM +0200, Jochen Sprickerhof wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: [email protected], [email protected] > > Control: affects -1 + src:tetrinetx > > User: [email protected] > > Usertags: armhf > > User: [email protected] > > Usertags: binnmu > > can you please trigger a binNMU of tetrinetx for reproduce.d.n: > > > > nmu tetrinetx_1.13.16-22 . armhf . unstable . -m "Rebuild to fix Depends:" > > > > We currently have this diff: > > > > -Depends: libadns1t64 (>= 1.5.0~0), libc6 (>= 2.38) > > +Depends: libadns1t64 (>= 1.5.0~), libc6 (>= 2.38) > > > > And I can't reproduce the buildd version with the 0 locally in a fresh > > sbuild chroot. I assume it was some bit flip on the buildds. > > The same happened on hppa, which rules out a bit flip. > > The root cause is in dpkg. > > I do not understand the source of non-determinism in the output, > but symbols with different but equal versions are used by tetrinetx: > > $ dpkg --compare-versions "1.5.0~0" "=" "1.5.0~" > $ echo $? > 0 > $ So the cause for this seems to stem from the adns symbols file containing most symbols with 1.5.0~ and a couple with 1.5.0~0 versions. Depending on how the symbols appear in the reverse dependency binaries, then the emitted versions would be either one of those. I think this should be fixed in adns, because this seems to be currently triggering "undefined behavior" from dpkg-dev tools. Then while pondering whether this should also be improved or changed in dpkg-dev tools, I thought there were two potential main avenues (or variations over these): a) The tools could normalize the versions, so that versions that are version-wise equal, but string-wise different would not cause this kind of problem. This would diverge from our current version handling which is "preserving", and could have unintended fallout. I don't think this is the correct way to go. b) The tools could start doing version-wise comparisons, and if the versions are equal, then do a string-wise comparison for sorting purposes. While this would preserve the versions and would solve this kind of problem, it seems rather cumbersome, and then we'd need to make any other tool evaluating versions do the same. So this does not look enticing either. Also similar issues can be triggered for example with versioned dependency simplification when combined with substvars generation (where different substvars could be generated in random order). So, I think just keeping it as "undefined behavior" from dpkg PoV looks fine to me, unless someone has a better idea, and getting adns fixed should solve this specific issue. The attached diff should accomplish this. Thanks, Guillem
diff --git i/debian/libadns1t64.symbols w/debian/libadns1t64.symbols index 97f9470..7d16f5c 100644 --- i/debian/libadns1t64.symbols +++ w/debian/libadns1t64.symbols @@ -24,10 +24,10 @@ libadns.so.1 libadns1t64 #MINVER# adns_processwriteable@Base 1.5.0~ adns_rr_info@Base 1.5.0~ adns_strerror@Base 1.5.0~ - adns_submit@Base 1.5.0~0 + adns_submit@Base 1.5.0~ adns_submit_reverse@Base 1.5.0~ adns_submit_reverse_any@Base 1.5.0~ - adns_synchronous@Base 1.5.0~0 + adns_synchronous@Base 1.5.0~ adns_wait@Base 1.5.0~ adns_wait_poll@Base 1.5.0~ adns_addr2text@Base 1.5.0~
