r-darwish / topgrade

Upgrade everything
GNU General Public License v3.0
3.36k stars 161 forks source link

Fix compilation on Debian Bullseye #879

Closed beckerj closed 2 years ago

beckerj commented 2 years ago

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

Standards checklist:

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 commented 2 years ago

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 commented 2 years ago

@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 (https://github.com/tokio-rs/tokio/pull/4457)

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

MCOfficer commented 2 years ago

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

beckerj commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.