Fix compilation on Debian Bullseye

[beckerj]

Setting tokio to 1.16.0 which is the last version compatible with debian bullseye rustc:
tokio-rs/tokio#4491

Standards checklist:

• The PR title is descriptive.
• The code compiles (cargo build)
• The code passes rustfmt (cargo fmt)
• The code passes clippy (cargo clippy)
• The code passes tests (cargo test)
• Optional: I have tested the code myself
  • I also tested that Topgrade skips the step where needed

If you developed a feature or a bug fix for someone else and you do not have the
means to test it, please tag this person here.

[r-darwish]

Sorry, but if tokio choose to stop supporting Buster then there's no reason for Topgrade to downgrade a dependency. Topgraded is supported in the latest versions of Debian and the latest Ubuntu LTS.

[beckerj]

@r-darwish Sorry, that was actually a mistake on my part that i now corrected. The issue is with debian bullseye, the current stable version:
Debian 11 (bullseye) comes with rustc Version: 1.48.0+dfsg1-2
Changelog of tokio 1.17.0: update minimum supported Rust version to 1.49 (tokio-rs/tokio#4457)

The end-result is topgrade upgrade via cargo will fail with:
error[E0658]: use of unstable library feature 'renamed_spin_loop'

[MCOfficer]

I'd argue that this is ok - end-users can always use the precompiled binary, and developers should use rustup anyways.

[beckerj]

The point here is, every install of topgrade that was installed using cargo install on debian bullseye fails right now, during the update of topgrade.
If you say I now need to upgrade it manually by downloading the binary that of course works for me, but somebody else might not know what the error means.
Also, I thought not having to do manual updates was the whole reason for topgrades existence.

Is there any reason tokio should not be 1.16?

[MCOfficer]

Having users get an unknown error is unfortunate for sure. We might be able to detect our MSRV and throw a warning or panic using rustc-version in the buildscript, that might be a workaround.

As for manually upgrading - no worries, topgrade will upgrade itself, so that should be ok.

Is there any reason tokio should not be 1.16?

None I can see immediately, but it would set a precedent about our MSRV. So far I believe we've stuck to whatever's on the oldest Ubuntu LTS. We (read: Roey) can now make the call whether to bind ourselves to debian as well, or drop it because ugh.

[beckerj]

As for manually upgrading - no worries, topgrade will upgrade itself, so that should be ok.

Unfortunately, this is not the case. The cargo install version runs with:
2022-03-28T07:46:41.830Z DEBUG topgrade > Self Update: false
which is not configured in topgrade.toml, so I assume it is default

[MCOfficer]

As for manually upgrading - no worries, topgrade will upgrade itself, so that should be ok.

Unfortunately, this is not the case. The cargo install version runs with: 2022-03-28T07:46:41.830Z DEBUG topgrade > Self Update: false which is not configured in topgrade.toml, so I assume it is default

The cargo version updates itself via cargo, the binary version should update itself. I use the binary for the most part, and it works fine. I'm not sure how topgrade infers what version it currently is, though.

[beckerj]

Problem just being that any installation of topgrade via cargo on debian is practically broken right now.
I get that you might not want to support cargo on debian, but maybe then there should be at least a note that installation should only be done by using the binary on debian.

[MCOfficer]

Problem just being that any installation of topgrade via cargo on debian is practically broken right now. I get that you might not want to support cargo on debian, but maybe then there should be at least a note that installation should only be done by using the binary on debian.

Agreed, there should be at least some way of knowing beyond the slightly hidden mention of "Rust 1.51" in the README. I'll look into perhaps spewing out a warning/error at compile-time.