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

[Ansgar]

Ximin Luo writes:
> 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.

Debian's repository format has costs for each package as we require
*all* users to process the entire Packages file which is already quite
large (42+ MB).  As long as we do so, we cannot add too much information
to this index.

Translating cheap dependencies from the cargo ecosystem into more costly
dependencies doesn't scale well.

We had similar discussions about tiny JS packages in the past: while
other package managers are fine with such things, Debian's repository
format isn't well-suited for such use.  I'm not really comfortable with
Rust doing this to a level that we should even introduce special
handling in the archive :/

(There are several alternatives to having all users download all of
Packages, but those don't exist in Debian and also have other
downsides.)

Note that this concern also applies to the use of `Provides` as this
information also ends up in the Packages index (though virtual packages
are cheaper than real packages).  Other language ecosystems seem, for
example, to do fine without having `Provides: foo-X, foo-X.Y, foo-X.Y.Z`
for each available package (plus the features part that rust does
there).

Ansgar