Support RISV64

[qdm12]

your feature request related to a problem? Please describe.

GOARCH=riscv64 go build ./cmd/golangci-lint

fails with:

/go/pkg/mod/github.com/prometheus/procfs@v0.1.3/cpuinfo.go:71:9: undefined: parseCPUInfo

Describe the solution you'd like.

I expect golangci-lint to be buildable for riscv64 as it is for all other platforms.

There is the dependency github.com/prometheus/procfs which added support for riscv64 in v0.6.0 (prometheus/procfs@910e685)

golangci-lint probably depends on many dependencies using versions pre-v0.6.0 of procfs so it's more of a long shot than something that can be fixed in a single PR I believe.

Describe alternatives you've considered.

go mod edit -replace=github.com/prometheus/procfs=github.com/prometheus/procfs@v0.6.0
go mod tidy

Fixes the build, but probably in a risky-ish way I guess. Not a priority issue at all, but I thought it would be useful to track it.

Additional context

No response

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Hello,

The replace directives are a major issue because they are not transitive.
As some people use golangci-lint with the "tools pattern", the replace directives are a problem.

In all cases, the replace directive is not the good solution to force the version of a transtive lib, the right way is to use // indirect.

[qdm12]

@ldez thanks for the heads up! Using go get github.com/prometheus/procfs@v0.6.0 && go mod tidy also fixes the build. Although I'm not sure it's that safe still compared to upgrading dependencies one by one 🤔

[ldez]

If that build and run it's safe 😉

The best way to handle that is to fix the root cause:

$ go mod why -m github.com/prometheus/procfs
# github.com/prometheus/procfs
github.com/golangci/golangci-lint/pkg/golinters
github.com/yeya24/promlinter
github.com/prometheus/client_golang/prometheus
github.com/prometheus/procfs

But the prometheus library is like the grpc or protobuf libraries: the root of a major dependency hell in Go, each patch or minor version can break your project because of the dependencies.

The "indirect" approach follows semver, the Minimal Version Selection (MVS), and it's transitive, then it a safe way.

[qdm12]

go mod why

TIL about this command thanks!

each patch or minor version can break your project.

Oh really? Don't they carefully follow semver?

The "indirect" approach follows semver

Are we sure it's safe though? I guess it still replaces older versions with 0.6.0 for all dependencies right? As in it does compile so that's good, but I can't guarantee it behaves the same as before right? Especially since these are 0.x.x releases (unstable).

Ill dig through their release notes and get back.

[qdm12]

Actually I was wrong, the RISCV64 fix came with release v0.3.0, not v0.6.0.

• Commits from v0.1.3 to v0.3.0: I don't think there is any breaking changes but can't be 100% sure yet
• Commits from v0.3.0 to v0.6.0: mostly bug fixes and new features, no breaking changes really

So we could use v0.3.0 to stay on the safe side, although v0.6.0 might be safer with the several bug fixes it comes with 🤔

[ldez]

I guess it still replaces older versions with 0.6.0 for all dependencies right?

It's not really a replacement: by using indirect we feed the MVS with new information, and MVS chooses the right version.

In all the cases, MVS chooses only one version of a dependency, then currently we use v0.1.3.

In golangci-lint, we don't really use prometheus or procfs, the dependency is only used by promlinter to parse metric's names.

Also golangci-lint is not designed to be used as a library, then we don't have to care about use in another context.

so yes it's safe 😉

[ldez]

If you want to be 200% sure:

• clone https://github.com/prometheus/client_golang
• checkout v1.7.1
  • https://github.com/prometheus/client_golang/tree/v1.7.1
  • https://github.com/prometheus/client_golang/blob/v1.7.1/go.mod#L11
• procfs is only used here:
  • https://github.com/prometheus/client_golang/blob/v1.7.1/prometheus/process_collector_other.go
  • https://github.com/prometheus/client_golang/blob/v1.7.1/prometheus/process_collector_other_test.go
• update procfs to v0.6.0
• then check the compilation and run the tests

=> everything works as expected

[ldez]

Still not confident? Want to be 300% sure? Check the diff between v0.1.3 and v0.6.0.

prometheus/procfs@v0.1.3...v0.6.0

There are no breaking changes of the API 😉

[ldez]

So don't be afraid:

1. we don't use procfs
2. github.com/prometheus/client_golang is compatible with v0.6.0
3. there are no breaking changes of the API between v0.1.3 and v0.6.0
4. we don't use procfs 😸
5. golangci-lint is not designed to be used as a library
6. go modules (and MVS) works well

Yes, it's safe 😄

Edit: I close the issue by mistake 😄