Hi Simon, Thanks for your work on gobject-introspection cross building!
On Wed, Jan 03, 2024 at 07:22:26PM +0000, Simon McVittie wrote: > - gobject-introspection-little-endian:any, a virtual package provided > by g-i-bin, which is Multi-Arch: allowed > (experimentally, apt and dpkg both seem to be happy to assume that > this makes the gobject-introspection-little-endian virtual package > behave as though it was also Multi-Arch: allowed) Let me guess that this is the culprit. I also Cc apt maintainers for their input. > Or do I need to make gobject-introspection-bin Multi-Arch: foreign, > drop the :any from gobject-introspection-little-endian:any, and > replace the gobject-introspection-bin | qemu-user | qemu-user-static > dependency by python3 | qemu-user | qemu-user-static or similar? I am not sure that you are the one who should express a qemu dependency. When we reason about dependencies, we care about how they behave assuming that you can run them. Whether you can run an executable from a package or not is something that is not expressed in our package relationships. It's also rather difficult. Consider a few corner cases: * Some amd64 can run i386. * Most arm64, but not all, can run armhf. * You may operate in a chroot with some external qemu-binfmt and thus execute any arch. * You cannot run hurd-i386 on amd64 even in the presence of qemu-user. I probably have caused this in our discussion back in Cambridge where I suggested to you that having a dependency on qemu could be ok. Given the above, qemu quite likely needs more thought. > My goal here is that you can install gobject-introspection:amd64 on an > amd64 machine, or on any other little-endian machine that will be able to > cross-compile amd64 binaries and then run them by explicitly invoking them > via qemu-user, as discussed with Helmut Grohne at the recent Cambridge > miniDebconf. (It has to be little-endian because g-ir-inspect and similar > tools don't currently support byte-swapping fields in binary typelibs.) When we considered whether cross building should imply disabling tests, we went for "no, but yes by default". When you cross build a package for i386 on amd64, sbuild and pbuilder will automatically add nocheck to DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES. However, you can opt out of this behaviour to really run tests despite performing a cross build. I think we need a similar mechanism for qemu integration. When we talked about this, I was having in mind (but probably didn't express this explicitly) that such qemu dependencies would happen in Build-Depends only. This is different from what you do here and has multiple implications: * Your satisfiability problem with britney2 probably goes away. * Every package that uses gobject-introspection needs to be modified for this. * We can annotate such qemu dependencies with a build profile e.g. <cross !nocrossemu>. By default, such dependencies would only become active for cross builds, but the second profile enables you to skip them when you know that no emulator is required. Other than this, let me note that M-A:allowed always seemed a little annoying to me, because it makes an implementation detail visible to consumers. Whenever you think you need M-A:allowed, you may instead introduce a layer of indirection. In principle, you could add a real binary packages: gobject-introspection-any-endian with Arch:any M-A:foreign Depends:gobject-introspection-bin and architecture-dependent provides. Then you can just depend on gobject-introspection-little-endian without thinking about whether you have to add :any. Let me also note that the way you have gobject-introspection (the binary package) now fills a similar role to pkgconf/pkg-config and qt5-qmake as well as binutils-for-host and hopefully soon also gcc-for-host. That pattern seems to work out rather well. This probably isn't the final solution, but I hope my feedback moves you forward in some way. Helmut
