Document our policy for Rust dependencies

We should document what our (experimental, subject to change) policies are w.r.t. new Rust dependencies in tor, somewhere in the doc/HACKING/ directory.

changed milestone to %Tor: 0.3.4.x-final in legacy/trac

added component::core tor/tor in Legacy / Trac milestone::Tor: 0.3.4.x-final in Legacy / Trac points::1 in Legacy / Trac priority::medium in Legacy / Trac resolution::implemented in Legacy / Trac review-group-35 in Legacy / Trac rust in Legacy / Trac severity::normal in Legacy / Trac sponsor::M in Legacy / Trac status::closed in Legacy / Trac tor-doc in Legacy / Trac type::enhancement in Legacy / Trac labels

Also we should probably figure out what our plans are for keeping our dependencies up-to-date.

The documentation on our policy is in my bug25310 branch. Additionally, I've added another commit for a script for updating/adding/removing Rust dependencies, at scripts/maint/updateRustDependencies.sh. There's documentation in the script, as well as in the dependencies section of doc/HACKING/CodingStandardsRust.md. Finally, I ran the script to test it how easy it was to use, and how intuitive its error messages were, by updating our current dependency on libc from 0.2.22 to 0.2.39 (there's a bunch of fixes, mostly for *BSD and Solaris systems). The changes for that are also included, and require merging my update/libc-0.2.39 branch (from https://github.com/isislovecruft/tor-rust-dependencies) into the tor-rust-dependencies repo.

Trac:
Status: new to needs_review
Keywords: N/A deleted, review-group-35 added

This LGTM. Should I take it 0.3.3 or earlier, or is 0.3.4-only fine?

Trac:
Status: needs_review to merge_ready

Replying to nickm:

This LGTM. Should I take it 0.3.3 or earlier, or is 0.3.4-only fine?

Whichever backports you're okay with? We started supporting Rust in 0.3.1, right? And I started documenting our standards in 0.3.2… so if you decide to backport, maybe take it back to 0.3.2?

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?

Replying to 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 !legacy/trac#2 (closed): 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).

I'm okay with doing just the script update (to not remove dependencies, and to allow duplicate copies) for now. :)

Updated versions which do not delete older dependencies are in my bug25310_r1 and update/libc-0.2.39_r1 branches respectively.

Replying to isis:

Updated versions which do not delete older dependencies are in my bug25310_r1 and update/libc-0.2.39_r1 branches respectively.

Err, to be more specific, bug25310_r1 should be merged into maint-0.3.3 and master in tor.git, and update/libc-0.2.39_r1 should get merged into master in tor-rust-dependencies.git.

I can't find bug25310_r1, and the update/libc-0.2.39_r1 branch appears to have no new commits. Did you forget to push it these? Am I looking in the wrong place?

Replying to nickm:

I can't find bug25310_r1, and the update/libc-0.2.39_r1 branch appears to have no new commits. Did you forget to push it these? Am I looking in the wrong place?

I uh… yes. Totally did not push them! Heh. Sorry sorry, they are there now:

https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25310_r1 https://github.com/isislovecruft/tor-rust-dependencies/tree/update/libc-0.2.39_r1

Woo. I think I have these merged.

I had to rebase the first one onto maint-0.3.3 first, to merge it to that branch. And I had to update the tor_log module to also use the second one. So it's possible that I've messed something up here. Please let me know if anything goes wrong. :)

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 8h

mentioned in issue legacy/trac#25664 (moved)

mentioned in issue legacy/trac#25664 (moved)

mentioned in issue legacy/trac#25664 (moved)