Package: debcargo Version: 2.5.0-2 Control: affects -1 src:rust-buffered-reader
debcargo 2.4.4 packaged rust-buffered-reader 1.0.1 with four non-virtual packages: librust-buffered-reader-dev librust-buffered-reader+bzip2-dev librust-buffered-reader+compression-dev librust-buffered-reader+compression-deflate-dev buffered-reader 1.1.1 does not differ in its features at all from 1.0.1, but when i try to package it with debcargo 2.5.0, it produces the following list instead: librust-buffered-reader-dev librust-buffered-reader+bzip2-dev librust-buffered-reader+compression-dev librust-buffered-reader+flate2-dev note that previously, …+compression-deflate-dev Provides: a virtual …+flate2-dev package. Now, …+flate2-dev Provides: a virtual …+compression-deflate-dev package. Note that the [features] section of the upstream Cargo.toml has not changed: -------- [features] compression = ["compression-deflate", "compression-bzip2"] compression-bzip2 = ["bzip2"] compression-deflate = ["flate2"] default = ["compression"] -------- This change does make for a consistency between the way the packages represent the bzip2 and flate2 features, but the fact that the non-virtual package name has changed means we're incurring a needless round trip through NEW, which incurs more friction between the rust and FTP teams. To avoid the friction, i'll probably work around by overriding the generated debian/control, but this is kind of a sledgehammer approach to fix a problem that i think debcargo was meant to solve. If there are any suggestions for how to handle this more gracefully, i'd be interested. --dkg
signature.asc
Description: PGP signature