Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Quoting Helmut Grohne (2024-09-28 07:07:55)
> On Fri, Sep 27, 2024 at 09:35:14PM +0200, Jonas Smedegaard wrote:
> > 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".
I like that description much better than my clumsy wording, and am sorry
for having missed your promotion of it. I shall try adopt it going
forward.
> 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.
Thanks for stating that - I was worried if you felt that my approach was
counter-productive to your (massive!) multiarch work.
> 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.
Yes. This is one of my reasons for trying hard to avoid the multiarch
interpreter workaround. The other reason being waste of both space each
time we build and add a binary package as multiple identical arch:any
packages instead of a single arch:all package.
> 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.
That third way makes good sense to me, and I suspect it also helps in
gaining a wider confidence in the use of multi-arch hinting among
developers: Currently one needs to wrap their head around an unreal
logic independent of material packages, whereas if multi-arch was a
more direct reflection on the grouping done in the distribution of
packages via APT, it might help to better relate to it. Or perhaps it
is just me struggling with the concept?
I wonder if perhaps debhelper tooling might be a stepping stone towards
that third way: I maintain dh-rust, and could perhaps make that compute
at build-time, whether each binary package would be safe to hint as
arch:all+m-a:foreign, or if instead it involves a (non-rust!) arch:any
dependency requiring it to itself a) become arch:any as well, and either
b) join a consistent "multiarch interpreter workaround" chain - i.e. if
that whole chain of dependencies are hinted as m-a:same then extend the
chain by adding the same hint for this binary package (the Rust team
"convenience maximizing workarounds" approach) or c) loose m-a hinting
for that binary package (my "minimizing workarounds" approach).
I imagine that integrating such mechanism into dh-rust (if I figure out
how to do it) will ease later large-scale changes to a third way, since
it then becomes less of editing within each source package to do the
transition.
Do you have any thoughts on that?
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
Reply to: