[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: tag -1 moreinfo

On Fri, 2016-09-30 at 02:08 +0200, Guillem Jover wrote:
> 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.
[...]

I know it's nonsensical, but this was done as a workaround for #827028.

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.

Please can you allow this 'nonsensical' case so that we are not forced
into a choice between two possible build regressions?

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy
others.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: