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.

Control: affects 1001251 + src:rust-sequoia-openpgp
with debcargo 2.4.4), rust-sequoia-openpgp+crypto-nettle-dev used to
Provides: rust-sequoia-openpgp+nettle-dev

but as of 1.7.0 (built with debcargo 2.5.0), it is the opposite:
rust-sequoia-openpgp+nettle-dev used to Provides:
rust-sequoia-openpgp+crypto-nettle-dev

The sequoia-openpgp packages are much more involved in terms of
features, and i don't really want to get into the business of overriding
debian/control there, so i'm just passing it on another trip through NEW
(it's in experimental anyway as it's blocked by the rust-random 0.8
transition temporarily).

Just documenting that this is an issue for more than a single crate.

Is your issue simply this? https://github.com/rust-lang/cargo/issues/7769

If so please close this bug as invalid, since it is not debcargo's responsibility.

X

Daniel Kahn Gillmor:

Hi Ximin--

thanks for the followup.

I think if this were fixed, then i could probably convince the sequoia
upstreams to mark the optional-dependency features as non-public,
leaving only their explicit, outwardly-defined features.  They're pretty
committed to API stability and they understand these details.

While cargo closing that bug would solve my specific problem (after i
convince the relevant upstreams to do the work to think it through), I
don't think that's the only way to solve it, and i also don't think it
solves the general problem.

Even if the rust ecosystem were to allow packages to offer non-public
features, there are still situations where public features could be
aliased to one another, and debcargo would need to choose one or the
other of them as a name for the feature package.  It should do this in a
deterministic way, both for simplicity and reliability, and to avoid
unnecessary churn through NEW.