[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency



Control: reassign -1 src:linux

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-sparc@lists.debian.org
> User: debian-sparc@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.

> As it happens, the :native arch qualification (according to the
> comments) seems to be a workaround for since-closed bugs in
> libdpkg-perl, but as far as I can tell, they should have been satisfied
> in this case.

So the assumtion here is that this is a problem in linux. Thus
reassigning.

Thanks,
Guillem


Reply to: