[buildd-tools-devel] Bug#809730: [Multiarch-devel] multiarch cross build dependency resolution

[Johannes Schauer]

Control: tag -1 + patch

Hi,

Quoting Johannes Schauer (2016-01-04 13:39:25)
> Quoting Colin Watson (2016-01-04 13:21:47)
> > On Sun, Jan 03, 2016 at 09:40:28PM +0100, Johannes Schauer wrote:
> > > What prevents a dummy package being used instead as it is done in the
> > > native case?
> > 
> > See https://bugs.debian.org/697298.  Using "apt-get install" rather than
> > "apt-get build-dep" fails to handle ":native" qualifiers on
> > build-dependencies.  Those are disallowed in Depends but allowed in
> > Build-Depends, so mangling Build-Depends into Depends is a bad idea in cases
> > where these particular semantics are important.
> 
> the :native qualifier has been taken care of for native builds with the patch I
> submitted for bug #777216
> 
> > Please don't get rid of this change - it's useful.
> 
> With that patch in place, why is it still useful?
> 
> > The native and cross paths differ only because I was being conservative about
> > changing things.  If you're working on this anyway, I'd prefer us to switch
> > to the build-dep approach across the board.  I have a to-do note in my local
> > copy to check whether both --resolve-alternatives and
> > --no-resolve-alternatives work properly with that, though.
> 
> What I would like to switch to would be for apt to use "apt-get build-dep
> foo.dsc" which would make the internal dummy repo unncessary. Unfortunately
> sbuild can only switch to this approach once apt supporting this is in
> old-old-stable. Until then it has to continue using dummy packages.
> 
> With that in mind: what is the advantage of using "apt-get build-dep" over
> "apt-get install"? The latter method is tried and tested with native builds.
> The former method is less tested as it's only used for cross builds. Why switch
> to the build-dep method?
> 
> As far as multiarch is concerned, they should behave the same way anyways, no?
> 
> As far as syntax is concerned the only difference is that the Build-Depends
> field allows architecture qualifiers, build profile restrictions and the
> :native qualifier. But the former two are handled by dpkg while the latter is
> rewritten to :${buildarch}.
> 
> The "apt-get install" method has the advantage that we are less dependent on
> apt doing the right thing. The more we let apt *inside* the chroot handle
> dependency resolution instead of libdpkg-perl at the outside creating dummy
> binary packages, the less flexible we are once new dependency constructs are
> introduced.
> 
> Things like cross building and build profiles are such an example. The apt
> inside the chroot needs to have no clue about build profiles because dpkg
> outside the chroot already did the necessary mangling.

attached patch removes 'apt-get build-dep' for cross compiling and instead
relies on the existing dummy binary package system. It seems to work fine for
the packages I tested.

In the commit message I again summarized the situation and discussed the
reasonings behind my thinking. If you think I forgot to consider something,
please speak up!

> > Now, regarding your problem at hand in #809730, this shouldn't get in your
> > way.  Even when using build-dep, sbuild should still use its dummy archive;
> > the difference is merely whether it uses the Packages or Sources file it
> > generates.  It would be worth checking whether the Sources file is being
> > generated properly.
> 
> Right, the problem in #809730 might just be that the Sources file is generated
> in a way that does not take build profiles into account. If it were, then apt
> would not need to know about build profiles (so even older apt would work).

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-When-cross-compiling-install-dummy-binary-package-in.patch
Type: text/x-diff
Size: 6161 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160106/d69a7d7e/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160106/d69a7d7e/attachment-0001.sig>