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

[Ximin Luo]

+pkg-rust-maintainers, -901827 bug report

Josh Triplett:
>> I wrote:
>>> In the Debian Rust team, we previously experimented with e.g. converting:
>>>
>>> - Cargo dependencies X (>= 6, << 7) into dpkg dependencies X-6 | X-7
>>> - Cargo dependencies X (>= 6)       into dpkg dependencies X-6 | X-7 | X-8 | X-9 | X-10
> 
> This is not equivalent to what I was referring to.
> 

How not?

> [..]
> 
>> You haven't been following the latest developments which are
>> plentiful; please take some time to get up-to-date before confusing
>> the discussion with irrelevant information.
> 
> 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.

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

> I'm not proposing to hide a problem; I'm proposing that, given that
> *both* approaches would benefit from dpkg support for version range
> dependencies, we should in the meantime attempt to accommodate the most
> common dependencies without that dpkg support.
> 

It is possible to revert to the previous behaviour but Sylvestre's concerns in issue #6 remain and I am starting to agree with him. I actually would just prefer to add an override to mdbook for the time being in order to forcibly add an extra dependency on slab 0.3.0, and link to this issue in the comments explaining that override.

X

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