On 2023-02-15 15:37 -0700, Sam Hartman wrote: > >>>>> "Fabian" == Fabian Grünbichler <debian@fabian.gruenbichler.email> writes: > Fabian> All in all it seems to me like the problem currently is more > Fabian> a theoretical one - it doesn't seem to cause (much, if at > Fabian> all) additional breakage on top of stuff that is already not > Fabian> cross compilable at the moment for other reasons. I admit to not having studied this properly, but I think this is the (farily) well-known 'multiarch interpreter' problem, when any arch-all package in the dependency chain 'loses' the inherited 'host-arch' value so all dependency resolution further down the chain is wrong. This doesn't matter if everything further down the chain _is_ arch-independent, but as soon as you hit something where the arch matters (e.g. a package which links to a C-library), stuff breaks. > It seems like if a librust-* package depended on some system library it > had a binding for, that's going to be a problem once the binding > generation works cross-compiled. Because if I'm understanding correctly > once you manage to get onto the wrong architecture's dependencies, you > will continue to use the wrong architecture. Correct. > However, adding a question to the mix, why does arch all work for go > packages? Good question. I don't know anything about go, but I assume it has the same problem as rust here, because it's also compiled and statically linked. Maybe we package it defferently so there is never an arch-all dep above an arch-any dep in the dependency chain? But in general this problem applies equally to any language where a dependency tree can have arch-any arch-all arch-any in the stack (and the bottom one needs to be the host arch) The rust form of this is slightly different because of the unusual 'source-included' scheme that rust's inability to dynamic-link has forced upon us. But (unless I misunderstand) the fundamental issue is the same. The ultimate problem here is that multiarch was designed with a 'C' mindset, so the assumption that architecture-dependencies would propagate down the chain (or things were arch-independent all the way further down) was implicit. The actually-quite-common-in-other-languages pattern where things were _mostly_ arch-independent (due to being an interpreted language, for example), but some random library in the dependency-chain (at least 2 levels down) might actually be a wrapper for an arch-specific C-library, was not considered in the design. The 'fix' (a workaround) is to make any packages which appear as the arch-all intermediaries in dep-chains to be made arch-any so that chain is not broken. We can either do that for all packages in an ecosystem, or just for ones that actually exhibit this problem. Doing it for all is safer. HTH Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature