On Tue, Jun 19, 2018 at 04:08:00AM +0000, Ximin Luo wrote:
> Josh Triplett:
> > While I *would* like to see support for version intervals, this
> > particular issue is a bug introduced through changes to debcargo. The
> > original debcargo intentionally generated versioned dependencies on
> > packages like librust-slab-0.3+default-dev rather than
> > librust-slab+default-dev. That would prevent this issue. [..]
> > Re-adding that will eliminate this issue.
>
> Josh, I'm well aware of what the previous debcargo behaviour was and
> it doesn't eliminate this issue, as I tried to explain in my previous
> comment:
I very carefully read your comment before replying.
> 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.
> > but this causes other problems (unwieldy dependency conversion logic) and
> > does
> > not really solve the problem described within this bug report, since it is
> > perfectly legal for separate Cargo crates to declare (= 6.1) (= 6.2) (= 6.3)
> > dependencies and Cargo will require all three to be installed even though
> > they
> > are (supposed to be) semantically compatible. In this case, we would have to
> > create new Debian packages called X-6.i (Provides: X-6 = 6.i) for i={1,2,3}
> > which puts us right back where we started. (Although granted it is unlikely,
> > assuming that everyone in the Rust ecosystem is sane and avoids this
> > forever.)
I've checked for that exact problem throughout the Rust crate ecosystem,
and found very few instances of it (some of which were quite fixable).
> 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?
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, where we generate dependencies based on
> versionless-package-names, based on a request from Sylvestre Ledru
> about the long-term maintenance of rust packages. I've been
> auto-building hundreds of variations of these Rust packages for the
> past few months; I'm well aware of the repercussions of both
> approaches and don't need to be reminded. After implementing
> Sylvestre's request I do think it's much cleaner; and the old way
> doesn't solve the problem it just hides it under the carpet and we
> will have to deal with it eventually anyway.
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.
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.
