Package: debcargo
Version: 2.7.8-3
Severity: serious
Justification: causes lots of policy violations
X-Debbugs-Cc: debian-cr...@lists.debian.org, debian-pol...@lists.debian.org
Hi,
we are writing down policy about Multi-Arch in #749826 and it is close
to completion. A significant aspect there is that the "allowed" value
should be used sparingly, because removing its use later tends to cause
installability issues. It should be the exception, not the norm.
Therefore policy asks uses of allowed to be discussed with
d-devel@l.d.o.
debcargo does the opposite. It issues allowed by default in stark
contrast to what the present policy draft requires. I request that
debcargo drops the issuance of the allowed value. Rust applications tend
to not load dynamic shared libraries and that is the case for which the
allowed value is reserved.
apt-cache show "*" | grep-dctrl -FMulti-Arch allowed -sPackage -n
gives a list of packages carrying "Multi-Arch: allowed". It is about
390. Of those, about 60 are from the Python ecosystem (most of which
with reason). Another 50 are due to binutils (which offers loading
plugins into the linker). Then there are 80 from the erlang/ejabberd
ecosystem where we may have to have a similar discussion. What remains
is 200 packages many of which (I guess more than 100) come from the Rust
ecosystem and many of which should not be M-A:allowed.
Given the huge chilling effects of this default, I think it should be
reverted as soon as possible and for trixie in particular. Individual
crates can override it in control.debcargo.hint to avoid breaking
reverse dependencies.
In many (but not all) cases, the packages should be Multi-Arch: foreign
instead. From a quick glance, sqv should be M-A:foreign.
Helmut
