Hi Adrian, thank you for weighing in!
Quoting Adrian Bunk (2023-07-20 01:27:10) > > Package: box64 > Architecture: amd64 arm64 ppc64el riscv64 > Depends: > libgcc-s1:amd64, > libstdc++6:amd64, > > A package must not assume that the user has other architectures enabled. why not? Is this codified in a policy somewhere? If foreign architectures are not enabled, box64 would just not be installable but there are tons of packages I cannot install on my system without the package itself being buggy (for example due to Conflicts). If I just drop these dependencies, that would make the package have an RC bug because box64 cannot function without amd64 shared libraries. > There is a general issue around such dependencies, and also the more specific > problem that permitting cross-architecture dependencies would also require > checking that migrating a package for one architecture does not break > dependencies on other architectures. > > For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might be an > option (untested). Those packages install their libraries into /usr/<triplet> which is not searched by the dynamic linker. Maybe some LD_LIBRARY_PATH trickery can make it work but those shared libraries are not meant for running actual binaries. Originally, box64 upstream shipped their own binary blobs of libstdc++.so.6 and libgcc_s.so.1 and installed them into /usr/lib/x86_64-linux-gnu/. This is of course not an option either as that would conflict with users who do have amd64 packages installed and would also make the package violate DFSG for shipping binaries without source. It seems that the correct way forward would be to teach britney about foreign architecture dependencies? I had a look at the britney source and it seems to ship with its own dependency resolver instead of relying on dose3, for example. Teaching it about foreign architectures looks like a massive change... Thanks! cheers, josch
signature.asc
Description: signature
