[Pkg-rust-maintainers] debcargo bin packages FTBFS because they need dev-dependencies

[Josh Triplett]

On Wed, Jan 31, 2018 at 03:49:04PM +0000, Angus Lees wrote:
> On Mon, 29 Jan 2018 at 02:56 Ximin Luo <infinity0 at debian.org> wrote:
> 
> > I'm also considering passing --all-features to `cargo install` in
> > dh-cargo, does that seem like a good idea too? Or perhaps we could generate
> > two binary packages, one with default features and one with all features.
> >
> 
> My opinion: I think we need to handle features case-by-case as part of the
> debian packaging of a particular crate, and we should default to the
> upstream crate's default.
> 
> "Features" in cargo are a conditional-compilation directive, and I think
> it's incorrect to say "all features" == "better".  In most cases I think
> we'll want to go with the upstream's default unless we have particular
> needs (a common case might be enabling off-by-default SSL support, because
> we're happy to require the extra build-dependencies to get privacy).

Agreed completely. I would suggest the following approach:

- Prefer to generate one binary package rather than multiple.
- Prefer upstream's default features.
- If we want a feature enabled that upstream doesn't enable by default,
  or a feature disabled that upstream enables by default, start out by
  talking to upstream, and see if they're willing to change the
  defaults. (For instance, SSL should be *on* by default; see RFC 7258
  among other things.)

As long as that approach continues to work, let's continue to keep
upstream's defaults.  Do we, at this time, have any specific cases where
we want to package a binary package and enable non-default features?