Bug#1103995: unblock: rust-debcargo/2.7.8-4
On Wed, Apr 23, 2025, at 9:44 PM, Helmut Grohne wrote:
> 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).
thanks for noticing it in the first place! this was "inherited" and simply
never evaluated/reconsidered.
see second debdiff, which does exactly that :)
>> [ 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/
yes, this no longer matches the last debdiff which switched to no M-A
annotation by default for "bin" type packages.
>> [ 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.
I agree with that in principle, but would still like RT's input on that given
the amount of packages (many of which would otherwise not see another upload,
except maybe a final binNMU to pick up changes in (transitive) statically
linked dependencies).
>> 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.
see second debdiff (and pending-debcargo branch in debcargo-conf). in the end,
I chose no explicit value over an "explicit" 'no', as that allows encoding a
decision to mark a crate as non-M-A in debcargo.toml and the source package's
d/control (even though the corresponding annotation is then removed when
building the binary package ;)).
> 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.
I think it makes most sense to only annotate those that either have a use
case requiring it or are otherwise clear cut. and it might make sense to
tackle this together with an attempt at improving M-A on the LLVM side,
and doing another pass over the rust toolchain annotations, at the start
of the forky cycle.
Reply to: