> For future release, a better way of handling this will be needed. The fact > that these updates break random other packages isn't really acceptable.
The fix in sid involved patching encoding_rs 0.8.15, which addressed the simd crate problem. The reason why simd complied previously and got packaged is explained by the build.rs hack in the simd crate. Upstream encoding_rs 0.8.16 no longer depends on the simd crate and instead depends on packed_simd, which doesn't have such a hack. Indeed, the hack was recognized as problematic upstream, and the present the harmlessness of the hack in encoding_rs's own build.rs now depends on the build failing in packed_simd when using the stable compiler. As reported, the failures were not only in the simd crate but also in coresimd, which was pulled in by packed_simd, which was pulled in as an optional dependency of the bytecount crate. None of these three crates have the build.rs hack, so the build for packed_simd and coresimd should have failed even before the recent rustc update in sid and buster. Indeed, if I try to build the corresponding upstream versions of bytecount and packed_simd with by invoking cargo build --features generic-simd from the bytecount directory locally with Rust 1.32 from rustup, the build fails in packed_simd due to use of unstable features. In the interest of avoiding future breakage, it would be particularly worthwhile investigate how it was possible that packed_simd and coresimd made it through the import as optional dependencies of bytecount and compiled with the previous compiler when they shouldn't have compiled. (Also: Why does the newly-uploaded version of packed_simd in sid compile now?) -- Henri Sivonen
