[buildd-tools-devel] Bug#695287: sbuild: synthetic cross-build-dependencies for compilers

[Guillem Jover]

Hi!

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

On Thu, 2012-12-06 at 16:54:23 +0000, Colin Watson wrote:
> Package: sbuild
> Version: 0.63.2-1
> Severity: wishlist
> User: crossbuild at debian.org
> 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.

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