[Pkg-rust-maintainers] Bug#901827: dpkg: Support two-sided version constraint ranges, required to properly translate Cargo dependencies

[Josh Triplett]

On Tue, Jun 19, 2018 at 04:54:00AM +0000, Ximin Luo wrote:
> Josh Triplett:
> > I have not seen the proposal or rationale to diverge from the previous
> > approach discussed on pkg-rust-maintainers at all; do you have a pointer
> > to where that was proposed and discussed?
> > 
> 
> It was on IRC and that's where much of the discussion happens, you're
> missing a lot by not being on it. Also on
> https://salsa.debian.org/rust-team/debcargo/issues/6 where you can see
> I was initially against the proposal until I implemented it.

Is there some means by which discussions on salsa could be automatically
copied to pkg-rust-maintainers, as BTS bugs are?

In any case, reading that issue, it's not obvious how this new approach
allows maintaining multiple versions of crates simultaneously, which
real rust packages *do* require. I regularly encounter Rust crates which
have dependency trees pulling in more than one version of a crate. One
of the points of putting the version number in the name is to allow
simultaneous installation of multiple versions. (That's not a bug to be
fixed, that's a feature of Cargo that arises in practice in various
upstream crates.)

> > I also very specifically said that I *do* want to see the proposed
> > improvement to dpkg regardless.  But a change to dpkg's version handling
> > won't be usable until after a subsequent stable release.
> > 
> >> I made the decision to do it the current way and diverge from the
> >> previous approach, [..]
> > 
> > On the contrary, the previous approach works for the majority of version
> > dependencies, as long as you don't want multiple compatible versions
> > simultaneously installed. As long as you don't hit that case, which the
> > vast majority of Cargo crates don't hit (I scanned for such dependencies
> > throughout the entire ecosystem at the time and found very few), then it
> > handles cases such as the one you originally posted just fine. And we
> > could always switch to the other approach after version range support
> > appears in dpkg.
> > 
> > By contrast, this approach to Provides and Depends seems to fail in the
> > most *common* cases of Cargo dependencies, including simple "compatible"
> > dependencies.
> > 
> 
> The old code was complex and took me many hours to get right, e.g. see all the commits from June 09 that I did. The previous version was buggy and would not work for some packages; that includes both your old code and Vasudev's work on top of it. The bug-free version has pretty complex logic that I don't think is easy for a newbie to grasp either.
> 
> By contrast the new code took me about 2 hours to write, and only fails for this mdbook case out of all of the transitive dependencies of {mdbook, exa, ripgrep, debcargo}, and only because dpkg cannot properly express what is needed for Cargo crates.

Last time I tried packaging using debcargo, the transitive dependencies
of ripgrep included multiple versions of more than one crate. That may
have changed in the interim, but I fully expect that kind of situation
to arise often.

And even if dpkg is fixed, you won't be able to make use of that fix
until that dpkg appears in a stable Debian.

- Josh Triplett