Hi Samuel, On Fri, Jun 19, 2020 at 07:25:41PM +0200, Samuel Thibault wrote: > We now have the cross-mig packages in the archive, and I have uploaded > gnumach & hurd to build-depend mig-for-host instead of mig.
Thank you for working on this. When you talk about cross toolchains, please Cc debian-cr...@lists.debian.org. Doing so now. > There are however two things that may pose problem: > > - mig-for-host:hurd-i386 is multi-arch: same and depends on > mig-i686-gnu: > > Package: mig-for-host > Source: mig > Architecture: hurd-i386 > Depends: mig-i686-gnu > Multi-Arch: same > [...] This part looks good to me. > and mig-i686-gnu:amd64 doesn't have a multi-arch field > (explictly removed in debian/rules, I don't remember why): > > Package: mig-i686-gnu > Source: mig > Architecture: amd64 > Depends: libc6 (>= 2.14), libfl2 (>= 2.5.33) > [...] > > Don't we want to make mig-i686-gnu:amd64 multi-arch:foreign so > that it can fill the dependency of mig-for-host and provide a > /usr/bin/i686-gnu-mig that can actually be executed? When I keep it > multi-arch:foreign things seem to be working fine. In principle yes. Since the target architecture is part of the package name and encoded in command names, we consider it not affecting the interface. This aspect is expressed via Multi-Arch: foreign. There is one major exception. Some tools (such as binutils) allow loading of plugins (shared objects). I'm not aware of any such system in mig, but for this reason, we cannot mark binutils-$triplet Multi-Arch: foreign. It is Multi-Arch: allowed instead. When you don't use plugins, you annotate the dependency :any. So please check for a plugin loading system before adding Multi-Arch: foreign. > - When I add_automatic mig, once the mig source package is cross-built > automatically, the result (mig:hurd-i386 mig-for-host:hurd-i386 > mig-i686-gnu:hurd-i386) replaces completely the mig_1 build > (mig-i686-gnu:amd64) which gets moved to archive/: > > ./archive/mig_1 > ./archive/mig_1/mig-i686-gnu_1.8+git20200618-2_amd64.deb > ./pool/main/m/mig > ./pool/main/m/mig/mig-for-host_1.8+git20200618-2_hurd-i386.deb > ./pool/main/m/mig/mig_1.8+git20200618-2_hurd-i386.deb > ./pool/main/m/mig/mig-i686-gnu_1.8+git20200618-2_hurd-i386.deb > > I guess it's the reboostrap automatic build that does not support > merging with previous builds for another architecture? Yes. This is a limitation of rebootstrap. It really is a hacky script that barely gets stuff built, but is relatively stupid otherwise. However, I think that this is irrelevant due to another issue. We need mig-for-host quite early. At that point, we don't have glibc yet. Therefore, we cannot build mig-i686-gnu yet. So we need some build profile that allows building mig-for-host, but not mig-i686-gnu to remove the (implicit) libc6-dev dependency. I don't think we have a standard profile name for this. We'll need a similar profile for binutils and gcc in the long run. I'm not sure whether it makes sense to standardise the profile name for three packages, so maybe use one from the per-package namespace. Helmut
