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

[Josh Triplett]

On Thu, Feb 01, 2018 at 01:57:00AM +0000, Ximin Luo wrote:
> 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?
> > 
> 
> OK, agreed we'll stick with the defaults for now.
> 
> I don't know of any cases like that but also haven't checked too closely.
> 
> It might be good to auto-generate a 2nd package with --all-features, but I'll collect more data before pushing that forward.

Even *if* we find that we sometimes want non-default features that
upstream doesn't want to enable by default, in general not all optional
features will even *build*. For instance, we can't turn on "nightly", or
simd-related features (which currently needs nightly), or clippy, or
similar.