Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support

[Helmut Grohne <helmut@subdivi.de>]

Hi Jonas,

On Fri, Sep 27, 2024 at 09:35:14PM +0200, Jonas Smedegaard wrote:
> Yes, The rule of thumb makes sense to me. Now as well as in 2023.

Thanks for confirming.

> So more accurately I mean convenience-arch:any(+m-a:same) - i.e.
> packaging arch:all code as arch:any and as a consequence hinting as is
> required for arch:any packages, as a convenience simplification of by
> default doing arch:all+m-a:foreign and only when needed doing the
> arch:any+m-a:same workaround.

I agree with your characterization of the use of Arch:Any + M-A:same as
a workaround. In many other mails I have named it the "multiarch
interpreter workaround". Being a workaround, I am not fond of it, but it
is the best tool we currently have at our disposal for a very specific
use case. As a result, I have no intention to emit any hints asking for
use of this workaround in cases where there is no technical reason for
doing so. In particular, rust libraries that entirely lack dependencies
are unaffected by the underlying problem and I have no objections to
keeping them Arch:all + M-A:foreign so long as they are properly
switched to Arch:any + M-A:same when they gain architecture-dependent
dependencies.

Whilst we apply this workaround in the name of cross building, it also
has negative effects on cross building. If those packages could be kept
as Arch:all, they'd trivially be supported in a cross build environment.
By switching them to Arch:any for the sole reason of transferring
dependency constraints, the build has to gain support for cross
compilation. This poses non-trivial additional effort.

In principle, there is a third way. The package manager could be
extended to allow treaing Arch:all packages as something other than
native. The status file would have to be extended and record a concrete
architecture for each installed Arch:all package (and that would default
to the native architecture). At installation time of a package, you
could opt for installing it as another architecture than the native one.
When doing so, the package manager would verify its dependencies for the
chosen architecture before proceeding with configuration and
DPKG_MAINTSCRIPT_ARCH would also reflect the chosen architecture. At
that point, we could convert many of the Arch:any + M-A:same packages to
Arch:all (though not M-A:foreign). This route has not proceeded further
as there is strong disagreement on the external interface (CLI) of this
functionality.

Helmut