Package: sbuild Version: 0.63.2-1 Severity: wishlist User: [email protected] Usertags: cross
(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, -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
