[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