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.