Hi Johannes!On Mon Jul 15, 2024 at 2:23 PM CEST, Johannes Schauer Marin Rodrigues wrote:
Quoting Andrea Pappacoda (2024-07-15 09:55:49)Since it can be only *used* on amd64, x86 and x32, I've always set the Architecture to "any", explicitly enumerated the architectures where the package can be used.that sounds sensible. This way, your package can be used to build package *for* x86 (the host architecture) but not for other architectures because you did not mark it as Multi-Arch:foreign.
You made me notice that I did not mark the package as MA:same. I don't remember if I did this on purpose, but now that I look at it I really think it should be marked as such.
Would this still be the case if I made the package "Architecture: all"? I believe you could still cross-build, since the package would be valid on all architectures, but I could also use it to build an e.g. native arm64 binary, leading to build failures.Cross-building would actually be made problematic by this. As for why, let me explain what Architecture:all means in the multiarch context. Since packages that are marked as Arch:all are completely identical independent on which system they are installed, apt and dpkg treat them as implicitly being of the native architecture as far as multiarch dependency resolution is concerned. So if libxbyak-dev were Arch:all, installing it on arm64 would implicitly make it an arm64 package for apt (and dpkg) and thus, if you now wanted to cross-build something for amd64, apt would be unable to install libxbyak-dev for amd64 as it only knows of libxbyak-dev for arm64. Usually, you get around this by marking Architecture:all packages with Multi-Arch:foreign. But if you would do this, then you could suddenly satisfy build dependencies for *all* other architectures. There is no Multi-Arch:some-foreign field which would tell the resolver that your package only provides an architecture independent interface for some architectures. So even if your package is identical on all architectures, leaving it as Arch:any is actually a valid technique to limit the architectures for which your package can be used to resolve dependencies.
Makes sense, thanks!
Should I proceed with making libxbyak-dev an "Architecture: all" package, or should I revert the upstream change? If so, should I double down on this, by also installing the headers themselves in arch-specific subdirectories of /usr/include?I think you should probably follow what upstream is doing. Other projects using this package will have certain expectations of how they want to find the library headers.
That's true, but here I'd just propose to revert the change upstream. This case is a bit special since the upstream build system has been contributed by me, and I'm generally the one who touches it -- it doesn't get touched very often though, this is a header-only library after all :)
As for moving the headers, yeah, that's probably undesirable. Some people are probably including stuff from /usr/include directly, without asking pkg-config for the correct include path.
What prevents you from keeping the upstream change but also keeping the current situation with libxbyak-dev being Arch:any? Since the package is only suitable for a select architectures, I think arch:any is superior to having it arch:all.
Nothing really, but I find it a bit odd to ship a Arch:any package which installs a pkg-config file in /usr/share. It would work for cross builds, but would also work in regular user builds outside (the ones performed outside of Debian package building). If a user installs libxbyak-dev:i386 on an arm64 machine, then its native arm64 pkg-config would find and reply with the contents of the .pc file under /usr/share even when performing non-cross-builds. Right? This would break a bit my expectations: when I install something to cross build, I wouldn't expect it to also become available for non-cross builds, especially because it wouldn't actually work.
Thanks for your help! Bye :)