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

[Ximin Luo]

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.

>> 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.

>> 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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git