[Multiarch-devel] multiarch cross build dependency resolution

[Johannes Schauer]

Hi,

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.

> 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: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/multiarch-devel/attachments/20160104/066afb67/attachment.sig>