[Pkg-rust-maintainers] Getting rid of the NEW step for binaries ?

[Ximin Luo]

Ansgar:
> On Thu, 2019-10-17 at 18:57 +0200, Sylvestre Ledru wrote:
>> Le 17/10/2019 à 18:52, Ansgar a écrit :
>>> Sylvestre Ledru writes:
>>>> Moreover, the creation (or deletion) of new packages is automatically
>>>> managed by debcargo (our tooling).
>>> Why do you need to automatically create/remove binary packages?
>>
>> Because it is the way it is managed in Rust packages. This is done to 
>> express what the package provides. For now, it has been working very well.
> 
> That doesn't answer the question why this is the case.
> 

In Debian, the unit of dependency resolution is a binary package. What I mean by this is that you can't say "package A sometimes depends on B1 and sometimes depends on B2". OTOH in rust's cargo package manager, this is possible via "crate features". Because this is possible and frictionless, crate authors do this frequently. To make this work in Debian in a large-scale way, our automated packaging tool converts crate features into separate binary packages (and has some basic heuristics on recombining these into a single binary package, when the dependency sets are identical.)

Note that it's not feasible (in a large-scale automated way) to bundle all the dependencies into a single Debian binary package "A-all-features depends on B1 and B2" because B1 and B2 may conflict either on the Debian side or on the rust side.

>>> From looking at the package with the insane large Provides field, it
>>> seems like it creates empty binary packages to avoid some dependencies
>>> on other development packages to safe ~50k of downloads?  I would
>>> suggest to just accept the 50k extra downloads for packages for people
>>> using the rust development packages rather than creating extra binary
>>> packages.
>>
>> Sure but this isn't directly related to this discussion. I also do agree 
>> that we should address this issue.
> 
> Hmm?  Adding new binary packages is the reason why packages end up in
> binary-NEW.  So this seems directly related to me.
> 

This is one small fraction of the cases that we're talking about in this thread as a whole. Granted, it is possible to do what you say by patching the crate Cargo.toml so that it triggers our heuristic of "recombining feature binary packages into one single binary package", but we don't have tooling yet to detect these cases automatically to know when to do this. OTOH, writing such tooling isn't a very motivating use of volunteer time, when it "just works" already and doesn't cause any concrete problems.

X

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