[Pkg-rust-maintainers] [Debian Wiki] Update of "Teams/RustPackaging/Policy" by Infinity0

[Josh Triplett]

On Wed, Feb 07, 2018 at 02:36:00PM +0000, Ximin Luo wrote:
> Josh Triplett:
> > On Tue, Feb 06, 2018 at 08:12:00PM +0000, Ximin Luo wrote:
> >> Right, it does not do that currently. For git2 we have:
> >>
> >> [features]
> >> curl = ["libgit2-sys/curl"]
> >>
> >> which cargo treats as "git2-with-feature-curl must depend on libgit2-sys-with-feature-curl"
> > 
> > AFAIK, debcargo should handle that correctly, by making
> > librust-git2-version+curl-dev depend on
> > librust-git2-sys-version+curl-dev. Does it not?
> > 
> >> For num-bigint we have
> >>
> >> [dependencies.rand]
> >> optional = true
> >>
> >> which cargo treats as "num-bigint-with-feature-rand must depend on the rand crate".
> >>
> >> and something similar for serde.
> > 
> > Does debcargo not handle that correctly already? It should.
> > 
> 
> Right. Currently neither of the above cases are handled, the feature gets folded into the bare crate via Provides: but its dependencies are not added as dependencies of the bare crate.

I just looked at the code, and it *appears* to do so, and I'm fairly
sure it did so in the original version, though it's certainly possible
that there's a bug there.

It absolutely *should* fold in those Depends, so if it doesn't, let's
fix that.

> >> OTOH, we also have various crates that have dependencies with "{ default-features = false }", e.g. chrono-0.4 on num-0.1-with-default-features-false.
> >>
> >> So for all of these reasons I think it would be cleaner in the end not to special-case the "default" feature by combining it with the bare crate (as debcargo currently seems to be doing). Rather, we should:
> >>
> >> 1. have the bare crate Provides: the X feature, only if all deps of X are satisfied by it (for any X, including X = "default"). From the output of the winapi-0.3 crate, it seems we're already doing this. if not, then X needs to go in a real separate Package stanza.
> > 
> > Debatable. We could perhaps have an option in debcargo (perhaps via the
> > config file) to split out +default-dev into a separate package. But
> > given that all library crate packages just consist of source code, why
> > does it matter? I'd rather intentionally bundled +default-dev into -dev
> > for developer convenience; we don't need *maximum* feature granularity.
> > 
> 
> It is debatable sure, but my reasoning is that since we need (1) ("conditional folding") for X != "default" anyways - e.g. see how the rust-winapi package is generated - so I think it is sufficient to just rely on (1) and not have extra logic that implements *un*conditional folding for the "default" crate.

I'm more thinking of individual developers installing packages; it seems
far easier to say "to get crate xyz with default features, install
librust-xyz-dev; if you want non-default features also install ..." than
to make librust-xyz-dev not even able to compile the default feature.

I'd also like to avoid excessive proliferation of tiny binary packages
that just have dependencies. If we fold +default-dev into -dev, that
should substantially reduce the total number of binary packages. If not,
then every crate with a handful of default features gets a handful of
additional dependency packages.

> >> 2. translate crate-dependencies to +default debian dependencies, unless it is annotated with default-features = false in which case we translate it to the bare debian package.
> > 
> > debcargo already does (2) exactly like that; it uses +default-dev if
> > default-features, or -dev if default-features=false.
> 
> Right, the reason I stated this is to emphasise my intention that (2) should be the only case where we special case treatment of the "default" feature; everywhere else we can just treat it like a normal feature called "default". Less special-casing => less bugs, hopefully.

I think it's reasonable to avoid the excessive proliferation of binary
packages.