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