build(deps): update sysinfo requirement from 0.15.3 to 0.16.2

[dependabot]

Updates the requirements on sysinfo to permit the latest version.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dvdplm]

The build errors here has nothing to do with the sysinfo upgrade. It is caused by breaking changes in funty 1.2 (a dependency of bitvec, which is a dependency of parity-scale-codec.

[dvdplm]

…but even after fixing the bitvec/funty issue, there is a problem on macOS that requires an update to libc version 0.2.86 where this PR is included.

@ordian Any thoughts on how we should handle breaking libc updates? AFAIK it doesn't follow semver and we don't use it directly.

[ordian]

@ordian Any thoughts on how we should handle breaking libc updates? AFAIK it doesn't follow semver and we don't use it directly.

this should probably be handled in crates that directly depend on it, e.g. rocksdb and/or in applications with Cargo.lock

[dvdplm]

this should probably be handled in crates that directly depend on it, e.g. rocksdb and/or in applications with Cargo.lock

So in this case here?

[ordian]

Actually, in case of libc, it might be a bad idea, because it's not possible to build two versions of it. So if some crate depends on the latest version, pinning it might cause more trouble than good. So the fix would have to go into Cargo.lock.

[dvdplm]

So the fix would have to go into Cargo.lock.

It's not checked in here. Do you think we should check it in then? That's not great either.

[ordian]

So the fix would have to go into Cargo.lock.

It's not checked in here. Do you think we should check it in then? That's not great either.

No, adding Cargo.lock here won't help. My point is that it should not be fixed here, but rather in the leaf application with Cargo.lock file with cargo update -p libc --precise <whatever>.

I kind of understand why libc doesn't follow semver: https://github.com/dtolnay/semver-trick#illustrative-example
but by pinning its version here we might create more problems in the future, cf rust-bitcoin/rust-secp256k1#204.

[dvdplm]

My point is that it should not be fixed here, but rather in the leaf application with Cargo.lock

Won't help our CI, but I see the point. We'll have to fix CI separately I guess.

[dvdplm]

Anyway, given that this upgrade here is far from necessary and requires a big number of crates to update to libc 0.2.86, I'll close this PR and punt on the upgrade.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.