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.
