Re: Question about Multi-Arch specifier on Arch: all packages
On Thu, Jan 18, 2024 at 08:12:23AM +0000, MOESSBAUER, Felix wrote:
> I quickly inspected some Architecture: all packages and basically none
> of them had multiarch specifiers. So the problem is probably bigger
> than expected. I'm wondering if there is a *technical* reason to not
> assume Multi-Arch: foreign on Arch:all packages? These anyways can only
> be installed once, so only this exact instance of a package is able to
> fulfill a dependency.
Yes, there is. Multi-Arch: foreign is an assertion / a promise on the
ways to interface with the package that declares it. Since the Debian
policy does not clearly define the "interface of a package", defining
Multi-Arch: foreign precisely has been difficult, so thus far it has
only been defined in terms of how it affects dependency resolution.
A while ago, I've done an attempt at documenting it in a more
policy-like way and that's available at
https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign.
Consider an Arch:all package that contains shell scripts only. While the
content of the package is architecture-independent, the behavior of the
contained shell scripts may still be architecture-dependent in multiple
ways. Any invocation of a tool that does not have
architecture-independent is sufficient to break the promise Multi-Arch:
foreign provides. It can be as simple as calling gcc, linux32, or
setting up a seccomp syscall filter. Often times, Arch:all packages also
expose their underlying dependencies (e.g. when they act as
meta-packages).
If you want to mark packages M-A:foreign, please be careful to not add
wrong ones as the multiarch hinter will propagate wrong markings to
further packages. And yes, getting more help with adding correct
M-A:foreign headers would be awesome.
Do you know about https://bootstrap.debian.net/cross_all.html? It's a
report that can help figuring out which packages should be investigated
to improve cross building. Keep in mind that currently, 35% of source
packages are cross bd-uninstallable and of the satisfiable ones about
20% fail to cross build. The satisfiability problem certainly is the
bigger one at this time.
If you are unsure whether M-A:foreign is appropriate for a particular
package, don't hesitate to ask here for review.
Helmut
Reply to: