Open rubdos opened 4 months ago
Teeeechnically, since we haven't been bumping the version for the zkgroup crate and changes usually aren't breaking, I would expect you to be able to [patch]
around this situation. But it is kind of annoying, yeah, and I haven't actually tried it.
would expect you to be able to [patch] around this situation
I think the [patch]
section does not allow disambiguating which zkgroup
reference to patch, although in my case "patch-em-all" would be fine. We can currently just use 0.51.1; on the next libsignal-protocol bump I'll test this out.
Another effect:
error: failed to resolve patches for `https://github.com/signalapp/libsignal/`
Caused by:
patch for `zkgroup` in `https://github.com/signalapp/libsignal/` points to the same source, but patches must point to different sources
There's a trick though:
[patch."https://github.com/signalapp/libsignal/"]
# The source and target refs are the same URL. If we add another / in there,
# cargo sees this as a valid patch. Very ugly workaround.
# https://github.com/rust-lang/cargo/issues/5478#issuecomment-1055365283
zkgroup = { git = "https://github.com/signalapp//libsignal", tag = "v0.56.1" }
... but that duplicates all transitive dependencies, yielding to other conflicts. Not ideal for now...
Definitely not ideal. As a workaround, though, you could patch
your own dependencies the same way, though, correct?
Definitely not ideal. As a workaround, though, you could
patch
your own dependencies the same way, though, correct?
Yes, correct indeed, that's what I went with for now:
[patch."https://github.com/signalapp/libsignal/"]
# The source and target refs are the same URL. If we add another / in there,
# cargo sees this as a valid patch. Very ugly workaround.
# https://github.com/rust-lang/cargo/issues/5478#issuecomment-1055365283
zkgroup = { git = "https://github.com/signalapp//libsignal", tag = "v0.56.1" }
libsignal-core = { git = "https://github.com/signalapp//libsignal", tag = "v0.56.1" }
signal-crypto = { git = "https://github.com/signalapp//libsignal", tag = "v0.56.1" }
ringrtc depends (currently) on:
Signal Android depends (currently) on:
On applications that use FFI, this doesn't really matter, because ringrtc and libsignal get pulled in independently. However, Rust applications that pull in ringrtc and libsignal in the same Rust dependency tree yield a conflict on
cargo doc
:Keeping the
ringrtc
git tag version spec in sync with apps is, in my opinion, only a band-aid here. Releasing on crates.io (https://github.com/signalapp/libsignal/issues/490) would probably resolve this correctly, because it allows to track the versions of the actual crates, instead of depending on a git tag. I'll submit a PR for bumping libsignal on this repo now.I'm not sure whether I should post this issue here or on libsignal itself. It might make more sense over there...