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

Attachment: signature.asc
Description: PGP signature

Reply via email to