On Mon, 7 Nov 2016 18:12:41 +0100 Andreas Beckmann <[email protected]> wrote: > Right, that should be > > Architecture: all > Multi-Arch: foreign
No. > I just verified that this is sufficient to have a package > > Package: test-default-libmysqlclient-dev > Architecture: any > Depends: > default-libmysqlclient-dev, > > built for i386 and install it on a amd64 chroot. The situation you tested is not the one that breaks cross Build-Depends involving default-libmysqlclient-dev. In the situation you painted above, the installed default-libmysqlclient-dev package would draw in libmariadbclient-dev-compat, libmariadbclient-dev and libmariadbclient18 all in architecture amd64. But as explained by Helmut in his initial report, the source packages require the development headers for the host architecture (i386) and not for the build architecture (amd64). By marking default-libmysqlclient-dev as Architecture:all, M-A:foreign, the affected source packages will be able to satisfy their cross Build-Depends but they will still not be cross-buildable because the wrong architecture mysql headers will get installed. > In general, how does it work to have arch:all build-depends (marked as m-a: > foreign and depending on arch:any packages) in cross-build scenarios? > > IMO it is wrong to require -dev packages to be arch:any if they could be > arch:all + m-a:foreign. Architecture:all packages are implicitly understood as the native architecture which, in a cross-build scenario equals to the build architecture. Thus, if a build dependency is Architecture:all and M-A:foreign, then all its dependencies will also be installed for the native/build architecture. In the case of default-libmysqlclient-dev this behaviour would make cross builds fail because they do not need the build architecture version of the mysql libraries but the host architecture version. Thus, default-libmysqlclient-dev needs to be able to hand down the host architecture requirement to its dependencies. With a M-A:foreign marking you remove this capability. I also see no other way to solve this situation than the solution Helmut proposed. Thanks! cheers, josch
signature.asc
Description: signature
