> > * Multi-Arch differs from 'same' (was: Architecture differs from 'all') > I think you mean s/differs from/equals to/ in the third item as that's > what the code says. > The comment in line 77 still refers to filtering Arch:all. > The comment in line 84 states that Arch:all packages cannot be M-A:same. > This presently is correct, but there is an effort to make dpkg support > that particular combination. This use raises the question of how dpkg > exposes such packages in the dpkg-query output and whether it should > print the "instantiated" architecture or "all" there. Would you mind > keeping the check for Arch:all in order to better handle this future > situation?
https://salsa.debian.org/debian/dh-builtusing/-/commit/980190fe4e660a611ae73e58e62f2139be6e04b0 Thanks for the review! > With the change implemented (as is), my understanding is that > libc-dev-bin can be used as that's M-A:foreign and then trips the > multiarch condition to be kept. I have added a regression test for the Multi-Arch: foreign case: https://salsa.debian.org/debian/dh-builtusing/-/commit/a73e247e1c85f48f5d6cd63eaac453f273366b73 Instead of testing libc-dev-bin:BUILD in a context where BUILD differs from HOST, I force a similar situation by explicitly installing a foreign dependency for i386. The test passes locally, so the change should be OK and I will be able to test for regressions. (It still fails on automated testers, but for reasons specific to autopkgtest before testing anything, so this can be ignored here.)
