Control: tag -1 + moreinfo Hi,
On Thu, 6 Dec 2012 16:54:23 +0000 Colin Watson <cjwat...@ubuntu.com> wrote: > (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. 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
signature.asc
Description: signature