[Pkg-rust-maintainers] Bug#1026769: rust-trust-dns-proto - uninstallable on architectures other than arm* and x86*

[Peter Green]

Package: rust-trust-dns-proto
Version: 0.22.0-1
Severity: serious

01234567890123456789012345678901234567890123456789012345678901234567890123456789
rust-trust-dns-proto has an "optional" (in the cargo sense) dependency on
rustls, since collapse_features is used*, this results in it depending but not
build-depending on rust-rustls.

rustls itself is written in portable rust. However it depends on ring which is
written in a mixture of rust, C and asm and current releases only support x86-*
and arm-*. There is upstream work to improve portability but I wouldn't feel
comfortable packaging a pre-release version of a crypto library and it looks
like s390x is still out of luck even with current upstream main

So the current situation is that rust-trust-dns-proto is uninstable on three
release architectures and is unable to migrate to testing, the question then
becomes what to do about it, I see three options.

1. Add architecture restrictions to the packaging so the features are
    only made available on the relevant architectures.
2. Add build-dependencies so the package is not built on architectures
    where rustls/ring is available. The request removal of the uninstable
    package by ftpmaster.
3. Disable rustls support in the trust-dns stack completely.

Option 1 is the best from the point of view of offering the widest range of
features on each architecture. Unfortunately debcargo is currently unable to
do this declaratively, it can only be done by overriding debian/control which
makes maintaining the package more annoying.

I attempted to implement option 1 with the 0.21.2-4 upload, but I screwed up
slightly and as I was about to fix my screwups, my changes were reverted by
siretart and he implemented option 2 in the 0.21.2-5 upload.

However the upload of 0.22.0-1 seemed to drop the implementation of option
2, leading to the package becoming uninstallable again.

Meanwhile over in trust-dns-client, Reinhard seemed to go with the option of
disabling rustls support.

I don't really mind which option we implement, but it would be good to have
a consensus and then do it consistently.

* If collapse_features was not used, the affect would be that the main binary package
   was installable, but the relavent feature packages were not. This would still
   prevent the package from migrating to testing.