Hi,
Quoting Andrea Pappacoda (2024-07-15 09:55:49)
> I have a question about what I should set in the Architecture field of the
> xbyak[1] package.
>
> Xbyak is a header-only library that implements a JIT assembler for x86
> architectures.
>
> 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.
> This approach though leads to three packages which almost have the exact same
> contents, since there's nothing to build. The only difference is in the
> pkg-config and CMake config files are installed; they get installed in the
> arch-specific /usr/lib subdirectory:
That sounds okay. The main problem you create by having your package be
Arch:any instead of Arch:all is duplication on mirrors. But your package is
only 60.9 kB small.
> Nonetheless, even the files stored in the arch-specific directories are equal
> across architectures:
>
> $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/xbyak.pc
> prefix=/usr
> includedir=${prefix}/include
>
> Name: xbyak
> Description: JIT assembler for x86(IA32), x64(AMD64, x86-64)
> URL: https://github.com/herumi/xbyak
> Version: 7.05
> Cflags: -I${includedir}
>
> By making the package "Architecture: any-amd64 any-i386", while
> redundant, I can be sure that cross builds work fine and doesn't get
> misused. For example, if I'm on arm64 I cannot install libxbyak-dev and
> use it to build an arm64 binary, but I can cross build an i386 binary by
> installing libxbyak-dev:i386.
Yes, that sounds good.
> 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.
> I'm asking this now because in the latest upstream releases a Fedora
> contributor modified the build system to install pkg-config files into the
> arch-independent directory, /usr/share/pkgconfig. You can find the two
> relevant patches (and discussion) here:
>
> - <https://github.com/herumi/xbyak/pull/186/commits> (be sure to read
> the commit messages)
This sounds like Fedora is struggeling with setting up the pkgconfig search
path for cross compilation. It sounds like they are trying to use the
build-arch pkgconfig search paths to build stuff for a host architecture that
needs a different search path. Maybe somebody on this list is more familiar
with Fedora.
> - <https://github.com/herumi/xbyak/pull/187>
>
> 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.
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.
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature