Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Hi!
On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote:
> debcargo, the tool used by the Debian rust team to streamline the work
> of transforming upstream crates into Debian source packages generates
> d/control entries for librust-* binary packages qualified as arch:any
> and M-A:same, in order to support cross compilation. This solution was
> suggested by dpkg developers (Guillem?) according to the following
> comment left in the debcargo source code:
Hmm, I had no recollection of having had such conversation or given
that recommendation. Checking the history for that comment, and the
IRC logs for #debian-dpkg around the same time, seems like that was
discussed there and apparently resolved, and I guess I mostly skimmed
afterwards over the conversation and mentioned I was glad it had been
resolved (but where I don't recall having spent time pondering about
it :).
> // This is the best but not ideal option for us.
> //
> // Currently Debian M-A spec has a deficiency where a package X that
> // build-depends on a (M-A:foreign+arch:all) package that itself
> // depends on an arch:any package Z, will pick up the BUILD_ARCH of
> // package Z instead of the HOST_ARCH. This is because we currently
> // have no way of telling dpkg to use HOST_ARCH when checking that the
> // dependencies of Y are satisfied, which is done at install-time
> // without any knowledge that we're about to do a cross-compile. It
> // is also problematic to tell dpkg to "accept any arch" because of
> // the presence of non-M-A:same packages in the archive, that are not
> // co-installable - different arches of Z might be depended-upon by
> // two conflicting chains. (dpkg has so far chosen not to add an
> // exception for the case where package Z is M-A:same co-installable).
> //
> // The recommended work-around for now from the dpkg developers is to
> // make our packages arch:any M-A:same even though this results in
> // duplicate packages in the Debian archive. For very large crates we
> // will eventually want to make debcargo generate -data packages that
> // are arch:all and have the arch:any -dev packages depend on it.
>
> https://salsa.debian.org/rust-team/debcargo/-/blob/master/src/debian/control.rs#L342
I'm afraid after a quick read, I'm failing to understand what this
comment is trying to convey. Some of the things it's saying seem like
would apply to frontends driving dpkg for example, others I'm not sure
what they refer to.
From my reread of the IRC logs, it seems like the thing this was trying
to avoid was the "multiarch interpreter problem", but then w/o having
really put much thought at all into this right now (so take this with
a huge grain of salt), this does not feel to me like the same issue
when it comes to arch:all packages shipping sources to be used to
build the actual binaries. But again take this more like me having
currently no opinion on it right now w/o investing some time to think
this thoroughly, than anything else.
I think Helmut is probably at a better position to at least give the
rationale he had at the time for this.
Thanks,
Guillem
Reply to: