[tor-bugs] #25310 [Core Tor/Tor]: Document our policy for Rust dependencies
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Mar 19 21:56:09 UTC 2018
#25310: Document our policy for Rust dependencies
--------------------------------------------+------------------------------
Reporter: isis | Owner: (none)
Type: enhancement | Status: merge_ready
Priority: Medium | Milestone: Tor:
| 0.3.4.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: rust, tor-doc, review-group-35 | Actual Points:
Parent ID: | Points: 1
Reviewer: | Sponsor: SponsorM
--------------------------------------------+------------------------------
Comment (by isis):
Replying to [comment:6 nickm]:
> Hm. I'm hoping that it's okay to take this in 0.3.3 and 0.3.4: it
rebases cleanly to 0.3.3, but getting it into 0.3.2 would take more
conflict-resolution than I have.
>
> Assuming that's the case, I made a branch called `bug25310_033` ... and
then I ran into trouble. If I don't update the libc dependency in tor-
rust-dependencies, then the build will fail. But if I do update the
dependency, then 0.3.1 and 0.3.2 will fail (assuming they use libc), since
the updateRustDependencies script will delete libc-0.2.2.22.
>
> Two options here:
>
> 1. Maybe we should update the updateRustDependencies.sh script so that
it adds new crates, but does not remove the old ones, since they may still
be needed for older Tors?
> 2. Maybe we should update all the old tor branches to libc-0.2.39 for
now, but also search for a better solution?
(Oh no… why do I feel like this is going to result in us eventually
implementing a custom dependency resolution algorithm… oh no… oh no…)
I feel like !#1 would be the best option for now? And probably I should
add a table in the README of tor-rust-dependencies, for each version we're
currently maintaining, like:
0.3.2
|| dependency || version ||
|| libc || 0.2.2.22 ||
0.3.3
|| dependency || version ||
|| libc || 0.2.2.39 ||
0.3.4
|| dependency || version ||
|| libc || 0.2.2.39 ||
|| rand || 0.4.2 ||
etc.? Then when a tor version drops out of support, we can remove
whichever dependencies are no longer in a maintained version? Does that
sound like a good idea? (Also document that we do this, of course.)
I guess the other thing to do would be to just keep them all forever…
doing so would at least allow someone to build older, unsupported tors
later if they wanted to.
I'll update the script to no longer remove dependencies and allow
duplicate copies of dependencies.
Re !#2: we might want to update 0.3.1 and 0.3.2 for now, if we care about
*BSD and Solaris (I think there's also a few *nix patches between 0.2.22
and 0.2.39 as well, but I didn't really look to see how vital any of them
were)? But then again, it means the next versions in those series will
build, while older/current ones will not (not sure how much we care).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25310#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list