search

asomers / ztop

Display ZFS datasets' I/O in real time
BSD 2-Clause "Simplified" License
69 stars 7 forks source link

Choose a good MSRV policy for ZoL #28

Closed asomers closed 1 year ago

asomers commented 1 year ago

ztop is binary crate, not a library one. So the MSRV should be determined by the various package builders for each supported OS. For FreeBSD, that's easy: there's only one package collection to worry about. But what about ZoL? What's the oldest Rust toolchain used in the package collection of a modern, widely-used distro? @penryu do you have any ideas about this?

penryu commented 1 year ago

Using cargo-msrv (which does a git-bisect-style search for the oldest toolchain that builds the project), the MSRV for ztop on linux is 1.62.1.

Using Debian as the posterchild for slow/stale packages, the rust toolchain packaged with the current Debian stable and testing are:

Other distros are a bit newer: *

It's also worth mentioning that some distros (Arch being one) list rustup specifically as a supported/recommended installation method.

So, as of now, I would say the MSRV for ztop on linux is effectively 1.62.1

[*] Versions determined by:

asomers commented 1 year ago

I was afraid that Debian's toolchain would be old. It looks like, if necessary, I could make ztop build on 1.57.0. But going back older than that quick gets into dependency hell. So I'm not going to try to accomodate 1.48.0. For future reference, do you know of any online source to find those package versions? Launching 7 containers is a lot of work to do everytime I'm tempted to raise MSRV.

penryu commented 1 year ago

Using cargo-msrv (which does a git-bisect-style search for the oldest toolchain that builds the project), the MSRV for ztop on linux is 1.62.1.

Forgot to include that the only build failure was the use of the total_cmp() method in src/app.rs, which was an unstable feature in 1.61.0.

As for online package version info... I would assume so, but the ones I tried to find yesterday still involved a lot of lookup overhead. E.g.

  1. visit https://www.debian.org/distrib/packages#view
  2. select "View the packages in the stable distribution"
  3. select the release name
    • but first, had to lookup what the current stable release name is...
    • it's bullseye
  4. select the "Rust" category
  5. scroll all the way to the bottom to get the version for the rustc package
  6. Go to (1) and repeat for "testing", etc.

I found this site that takes a lot of the scrolling and clicking out of the process, but it still requires looking up which of the releases of a given distro is current, ... and some distros have different definitions of current:

https://pkgs.org/download/rustc

So launching containers are certainly a waste of bandwidth, but easier for me to script and run on a VPS in a data center and go for coffee. 😅

And as for Debian stable... I started there to get the bad news out of the way. Stable is notoriously out of date, and people who use it are generally prepared for it. In this case, 1.48 is so wildly out of line with the other distros that I wouldn't hesitate to tell users, "Upgrade to testing, or use rustup."

Alternately, by targeting the musl alternative to glibc, it's possible to produce a fully static ztop binary that would work on any linux that provides the /proc/spl/kstat/zfs portion of procfs. This could conceivably be built in CI and provided as a release.

asomers commented 1 year ago

Ugh. I was afraid that this was going to be complicated, but it's even worse than I feared. I think I'm just going to ignore the problem until a volunteer shows up who is willing to maintain packages for one or more Linux distros. Once such a volunteer is in place, then I'll cater to whatever MSRV they need. Thanks for your investigation.

penryu commented 1 year ago

FWIW, the use of a static[*] binary seems to be pretty common delivery format for Rust standalone tools. A few examples:

In each case they release tarball (or zip archive) of a ready-to-run binary for macos, windows, and linux. In starship's case, they also build an MSI package.

[*] Virtually all Darwin binaries technically have a runtime dependency on libSystem, due to Apple's aversion to being asked to follow even their own standards... But this is usually not an issue in practice.

I might try my hand at one of these pipelines in my fork and see how it works. And if you're interested, I can open a PR. What do you think?

asomers commented 1 year ago

On Sun, Mar 26, 2023, 5:45 PM Tim Hammerquist @.***> wrote:

FWIW, the use of an static[*] binary seems to be pretty common delivery format for Rust standalone tools. A few examples:

In each case they release tarball (or zip archive) of a ready-to-run binary for macos, windows, and linux. In starship's case, they also build an MSI package.

[*] Virtually all Darwin binaries technically have a runtime dependency on libSystem, due to Apple's aversion to being asked to follow even their own standards... But this is usually not an issue in practice.

I might try my hand at one of these pipelines in my fork and see how it works. And if you're interested, I can open a PR. What do you think?

It doesn't seem like a good idea to me. Ztop doesn't even run on windows and osx, and IMHO there's little advantage to precompiled binaries for Linux or FreeBSD. Plus, there's like 800 different architectures to build for.

penryu commented 1 year ago

Oh definitely: windows and mac don't make much sense. I was only thinking in terms of making Linux distribution easier. But I take your point. 👍