(This is a bit of an RFC.  I think I understand the general shape of the
problem, but I'd welcome comments on the design.)

One of the problems we have with cross-building packages is with
alternative compilers and other cross-tools.  Generally speaking,
cross-build chroots start with a reasonable set of cross-tools
preinstalled, such as gcc-HOST and pkg-config-HOST.  If somebody
build-depends on pkg-config, pkg-config-HOST is already installed so
it's OK.  However, if somebody build-depends on, say, g++-4.6, then
nothing knows how to install g++-4.6-HOST; or I can easily imagine that
we might want a gobject-introspection-HOST in the future.  It does not
seem correct to me to deal with these problems by adding more and more
packages to the cross-build-essential set.

When I was writing my patch for #695203, it occurred to me that this
offered an opportunity for sbuild to step in and synthesise
build-dependencies in some situations.  A possible design would be as
follows:

  When cross-building, if the package being built build-depends on A
  (taking any [] into account), A is not Multi-Arch: foreign, and A-HOST
  exists in the apt cache, then rewrite the build-dependency to
  "A:native, A-HOST" (including any versioning present).

Wookey suggested that we might also want something for people who don't
use sbuild; I think perhaps a similar algorithm in 'dpkg-checkbuilddeps
-aHOST' would be useful and reasonable.  (CCing debian-dpkg.)  An
alternative to the "exists in the apt cache" rule, which I can imagine
being troublesome, might be to have a hardcoded list of relevant
packages; this would change from time to time but hopefully not too
often.  Or we could have a package control field for "there's a cross
version of this".

Does this sound right to you?  I think I could probably figure out how
to do this on top of my previous patch, but I'd like to make sure that
we agree on the design first.

Thanks,

I think this all sounds reasonable.  I'll be happy to look over any
cross-building stuff for sbuild; I'm afraid my multiarch knowledge
is still lacking some of the intricacies though.  It's certainly
not a problem to add additional dependencies to the dependency
package when cross-building.

We might also want to look a bit further at automatically setting up
the appropriate foreign arches in dpkg/apt so that this is all
automatically installable as well (unless this was already taken
care of--I can't recall offhand), if we end up with multiarch
deps which would otherwise not be available.


Regards,
Roger

Hi!

(Re-redirecting, as the debian-dpkg mailing list is configured to
automatically redirect bug mails to debian-dpkg-bugs.)

Some quick thoughts, I'm not too fond on hardcoding the package naming
pattern in such low level tools (but then we do this already for the
path names of those tools). This assumes all packages have been properly
marked already with M-A:<value>. For dpkg-checkbuilddeps, yes, apt is
not (currently) an option, as that'd be a layer violation, and it would
exlude other frontends (I've some ideas on better integration with
frontends that could render this a non-issue, but not right now).
There's lots of toolchains, for different languages and runtimes,
hardcoding a list of those is really not appealing either, so
something generic would be my preference. An small issue with handling
the implicit mapping is that we might require more Build-Dependencies
than strictly needed, as some might only be used either for host or
build targets.

Thanks,
Guillem

For toolchain packages like gcc-4.7, you can't deduce the build dependencies
automatically. Cross building the gcc-4.7 package (not building the cross
compiler) requires additional build dependencies, which for a native build are
used from the current build. These are:

  g++-<target-triplet>
  g++-multilib-<target-triplet> [<target-multilib-archs>]
  gobjc++-<target-triplet>
  gobjc++-multilib-<target-triplet> [<target-multilib-archs>]
  gfortran-<target-triplet>
  gfortran-multilib-<target-triplet> [<target-multilib-archs>]
  gccgo-<target-triplet>
  gccgo-multilib-<target-triplet> [<target-multilib-archs>]

If these should not be hard-coded in the build tools, then we do need some
syntax for the control file to specify these cross build dependencies, best in a
way which is independent of the target architecture.

  Matthias

[...]

I think that's covered by something along the lines of Guillem's
profiles proposal, which would allow such things to be annotated with
<cross>.  I'd still like to be able to deduce as much as possible
automatically, though, because given the relatively small number of
people who care about cross-building it takes a very long time to
annotate lots of packages manually; the more we can do automatically the
better.

Hi,

we now have crossbuild-essential-$hostarch packages which depend on the
respective essential crossbuild packages to compile for $hostarch. Sbuild also
already automatically adds an implicit dependency on
crossbuild-essential-$hostarch if $buildarch is unequal $hostarch.

Would you agree that this fixes this bug?

Thanks!

cheers, josch