Hi Thorsten & Reiner, Quoting Thorsten Glaser (2020-03-14 18:26:24) > >Enabling M-A:foreign for musl-tools is unfortunately currently not > >possible. It's not arch:all, as it ships a few arch-dependent files. > > That’s true for other packages as well. > > A package can, generally, be made Multi-Arch: foreign, if it, and > all of its dependencies, can be used on a foreign system which has > the capability to execute its code (e.g. i386 on an amd64 system, > or anything with qemu-user-static).
you are right. Even arch:any packages are allowed to have a m-a:foreign annotation. Unfortunately, there are more conditions than the one you name before it is correct to mark a given package as m-a:foreign. > >E.g. the spec file, /usr/bin/musl-gcc (which hardcodes the arch-dependent > >path to the spec file), and /usr/bin/musl-ldd, which is a symlink to > >libc.so. > > Yes, but that’d be deliberate. Installing a foreign-architecture > musl-tools would then enable one to cross-compile. At least that’s > the idea. I’m not completely sure it’s the right way or even a good > way, or whether it’ll break $things, which is why I added the two “cross” > guys in Cc. I only had a very quick look at what musl-tools does but I do not think that it is correct to mark it as m-a:foreign. /usr/bin/musl-ldd is a direct symlink to /lib/x86_64-linux-musl/libc.so and /usr/bin/musl-gcc just calls /usr/bin/cc with /usr/lib/x86_64-linux-musl/musl-gcc.specs as a spec file. Both of these things make the interface provided by the package musl-tools architecture dependent. This means that a package that musl-tools:amd64 will give you different functionality compared to musl-tools:i386. For more context, read this handy write-up by Helmut: https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign Thanks! cheers, josch
signature.asc
Description: signature
