Hi! On Sat, 2016-10-01 at 21:07:30 +0100, Ben Hutchings wrote: > On Fri, 2016-09-30 at 02:08 +0200, Guillem Jover wrote: > > On Thu, 2016-09-29 at 13:39:30 +0100, James Clarke wrote: > > > Package: libdpkg-perl > > > Version: 1.18.10 > > > Control: affects -1 src:linux > > > X-Debbugs-Cc: debian-sp...@lists.debian.org > > > User: debian-sp...@lists.debian.org > > > Usertags: sparc64
> > > Currently, src:linux FTBFS in experimental on sparc64[1], with the error: > > > > > > dpkg-checkbuilddeps: error: Unmet build dependencies: openssl:native > > > > > > However, as you can see from the build log, openssl_1.1.0b-1(_sparc64) is > > > installed. This is the version from experimental, rather than the version > > > from > > > unstable which is used on all the other buildds, since sparc64 is unable > > > to use > > > the aspcud resolver[2], and so the apt resolver ends up pulling in more > > > experimental packages than actually needed, but if and when openssl 1.1.0 > > > hits > > > unstable, this will affect *all* architectures. This is because > > > Multi-Arch: foreign was added to openssl 1.1.0 in experimental (see > > > #827028), > > > and it seems _find_package in /usr/share/perl5/Dpkg/Deps.pm:1472 requires > > > :native dependencies to not be Multi-Arch: foreign. > > > > Yes (as mentioned on IRC), this is as intended and documented in > > deb-src-control(5). The rationale is that a :native build dependency on > > M-A:foreign package is non-sensical, one of the markings is wrong > > because if the interface is arch-indep then requesting the native > > should not be required. > [...] > > I know it's nonsensical, but this was done as a workaround for #827028. This was just what I deduced could be the implicit rationale for that behavior. > You seem to be saying that dpkg won't allow an M-A foreign package to > satisfy a :native dependency, even if the package is native. Which > would mean we can't both support cross-building with openssl 1.0, and > building with openssl 1.1, from the same source package. I think in this particular case, the correct solution is to also fix openssl 1.0 in unstable with the correct annotations so that there's no divergence between the suites. Is there any reason that would be problematic? > Please can you allow this 'nonsensical' case so that we are not forced > into a choice between two possible build regressions? I've contacted the original authors of the MultiArchCorss spec, and they confirmed the reason for the current behavior. I've also been talking with Helmut Grohne and Johannes Schauer about this, and we were pondering that it might indeed make sense to relax this restriction, but I'd probably like to discuss it with a wider audience before changing it. Thanks, Guillem
