coreutils
coreutils copied to clipboard
run cargo upgrade and fix any incompatibilites
Some of the libraries were getting somewhat out of date. I'm not sure why dependbot doesn't pick all these up, but good to do this occasionally assuming the updates don't break anything.
Great! Could you split this up over multiple commits so we can review (and revert if any issues pop up) them individually?
Will do - do you mean multiple PRs or multiple commits within a PR?
multiple commits within a PR :)
There was one problem - the https://github.com/dtolnay/unicode-ident project updated its license (it looks like maybe this is happening to all unicode libraries) so that it is no longer compatible with the deny.toml file. I cleaned up that file also (there was a lot of old cruft in it) but had to add the line to allow this license: "Unicode-DFS-2016". I'm not sure if there is a legal review process here, or how this should be handled. It appears that this was a "license clarification" rather than a new license that was added, so it doesn't fix any problem to go to the old version. Not sure how this should be handled. Note that the license IS listed on the OSI page: https://opensource.org/node/1077 as an open source license, but obviously this is different than any of the existing ones.
Looks like an acceptable license to me. Definitely compatible with MIT.
OK - split into 5 commits now - any more doesn't seem to make much sense.
It turns on the RUST_MIN_SRV parameter is pretty problematic for a lot of updates. I'm not sure I fully understand the value of trying to keep this "so far" behind. Since this is mostly executables, it doesn't seem like this will cause any problems for end users as long as we stay on a stable version. Of course there is likely a lot more discussion on this, so as an alternative this PR could just be closed until you decide to bump to a newer version of Rust.
I'm not sure I fully understand the value of trying to keep this "so far" behind. Since this is mostly executables, it doesn't seem like this will cause any problems for end users as long as we stay on a stable version.
The reasoning is that not everybody uses rustup. Especially if we want uutils to ve packaged by linux distros, we need to be compatible with the Rust versions in those distros (e.g. Debians Rust). The upgrade policy is generally just "we keep an MSRV until we find enough reason to bump it". This could be because it cleans up some code or because dependencies require a certain Rust version. If you feel like we should bump it again, feel free to open an issue with your reasoning.
Oh and we usually do a release before bumping the MSRV.
This PR has been superseded by https://github.com/uutils/coreutils/pull/3829. We'll bump the MSRV soon like you suggested (but probably not all the way to 1.62). Thank you for your work on this @andrewbaptist!