Bug#1103995: unblock: rust-debcargo/2.7.8-4

[Helmut Grohne <helmut@subdivi.de>]

Hi Fabian,

On Wed, Apr 23, 2025 at 08:21:48PM +0200, Fabian Grünbichler wrote:
> [ Reason ]
> until the version desired to be unblocked, debcargo defaulted to generating
> packages shipping executables ("bin" packages in debcargo's terminology)
> annoted with Multi-Arch:allowed. The patches included in this unblock request
> change this default to "foreign", with the option of overriding it via
> debcargo.toml.

Thanks for picking up the matter this promptly. However, "foreign" is
not a suitable default value either. Effectively you'd be promising that
any program written in rust would behave in an architecture-independent
way. The default should be "no" really (and that is the default for
Debian packages in general).

> [ Risks ]
> none of the packages currently maintained by the Rust team (see attached list)
> with Multi-Arch:allowed have any reverse-depends annotated with :any, so
> switching those to foreign should be fine.

s/switching those to foreign/switching those away from allowed/

> [ Other info ]
> In case the decargo update is unblocked, please also indicate whether you want
> a mass-upload of affected packages with the new default (to get rid of about
> 1/3 of :allowed Packages in Trixie!), or whether such changes should be
> evaluated on a case-by-case base and only packages that either have a good
> reason like sqv, or would be uploaded anyway, should be changed.

I recommend getting rid of most "allowed" annotations. If we do not,
people may add :any annotations and then when we upgrade from trixie to
bookworm, those dependencies will become unsatisfiable. The sooner we
remove excessive use of "allowed", the less breakage we have later.

> If preferred, a variant of the proposed changes with a default of "no" would
> also be possible (and would still allow sqv to easily switch to "foreign")..

Yes, please.

I expect that many packages that presently are marked "Multi-Arch:
allowed" would benefit from being "Multi-Arch: foreign". A quick glance
yields the following packages as likely candidates as their non-rust
counterparts are already "Multi-Arch: foreign".
 * alacritty
 * brotli-rs
 * rust-coreutils
 * diffr
 * rust-diffutils
 * rust-findutils
 * ripgrep
 * sudo-rs

On the other hand, it is questionable whether cargo-c should be
"Multi-Arch: foreign".

In general, there is a risk involved with marking stuff M-A:foreign, so
I wouldn't recommend rushing those annotations into trixie especially
when there are no reverse dependencies.

Helmut