New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: go list std returns no packages #31313
Comments
@josharian thank you for taking care of the issue and the report here!
I'm running openSUSE Tumbleweed, the (default) go package can be found here:
Sorry for the confusion, I tried multiple versions of go, like this development version of go1.12: I did not modify anything by hand until I found out that a usual download from https://dl.google.com/go/go1.12.2.linux-amd64.tar.gz and a manual modification of GOROOT/GOPATH works like a charm.
It's by the distributions package. Do you think it would be possible to not ignore symlinks when running |
cc @bcmills @jayconrod for cmd/go It is not clear to me whether the right fix here is in cmd/go or in the upstream distribution. |
I think this is an issue with the upstream distribution. Symbolic links cause a lot of issues with directory traversals, and they aren't supported on all platforms. If we followed them, it would very likely introduce bugs, and it would break projects that rely on the current behavior. Note that in GOPATH mode, we do follow symbolic links for specific packages (e.g., I think |
@saschagrunert do you have any interest in opening an openSUSE issue? In the meantime, it appears that you have found a workaround (download the package directly). Given that, and given that is doesn't appear there are any changes forthcoming on the cmd/go side, I'm going to close this. Feel free to comment if you think that we should re-open and discuss more. |
This was initially reported as dvyukov/go-fuzz#234. I've migrated it here as we investigate further, since this appears to be the correct home for it.
@saschagrunert reports that:
And provides this command and results:
This breaks go/packages.
@saschagrunert I have a couple of questions:
go/1.11
. Any idea why there is this disparity? Are the Go 1.12.1 std sources present, and if so, at what path? (And what doeswhich go
report?Thanks for your help tracking this down.
The text was updated successfully, but these errors were encountered: