Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#60537 - [go] godoc binary is not included with installation

Attached to Project: Community Packages
Opened by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 19:35 GMT
Last edited by Morten Linderud (Foxboron) - Monday, 22 October 2018, 20:38 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Morten Linderud (Foxboron)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Since Go 1.10 the godoc binary has been included with binary release of the Go programming language. The Arch Go package does not include the godoc binary, leading to some broken behaviour in tools that assume access to the godoc binary in $GOROOT/godoc. See https://dl.google.com/go/go1.11.1.linux-amd64.tar.gz for example.
This task depends upon

Closed by  Morten Linderud (Foxboron)
Monday, 22 October 2018, 20:38 GMT
Reason for closing:  Not a bug
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 19:36 GMT
This should be an easy fix, so I'm wondering how I could go about contributing this fix?
Comment by Morten Linderud (Foxboron) - Monday, 22 October 2018, 20:04 GMT
What tools assume `$GOROOT/godoc`? Why isn't providing `godoc` through `go-tools` adequate?
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:05 GMT
Visual Studio Code's Go plugin assumes `$GOROOT/godoc`. Does `go-tools` install it into this location? If not, should the Arch package not attempt to do what the binary release instructions do?
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:05 GMT
Sorry, `$GOROOT/bin/godoc` of course.
Comment by Morten Linderud (Foxboron) - Monday, 22 October 2018, 20:19 GMT
`godoc` has been moved out of the maintree into the `x/tools` sub repository ages ago. What go do have is `go doc`. Depending on the location `$GOROOT/bin/godoc` is a bug at their end.
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:33 GMT
  • Field changed: Percent Complete (100% → 0%)
So we ignore the fact that `$GOROOT/bin/godoc` is included in every binary release of the Go programming language? I'd like to know why we think that is the correct choice.
Comment by Morten Linderud (Foxboron) - Monday, 22 October 2018, 20:33 GMT
The binary release doesn't really matter. It's not included in debian either.
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:35 GMT
I'll gladly open a bug against Debian too. I think the binary release should be the source of truth on the expected structure of the installation. Otherwise, what is? Why is `gofmt` in `$GOROOT/bin/gofmt`?
Comment by Eli Schwartz (eschwartz) - Monday, 22 October 2018, 20:35 GMT
"broken behaviour in tools that assume access to the godoc binary in $GOROOT/godoc"

Well, you know what happens when you assume things. You make an ass out of you and me.
Comment by Morten Linderud (Foxboron) - Monday, 22 October 2018, 20:37 GMT
We build everything as golang intend us to build. `gofmt` is there, `godoc` is not. Nothing is omitted.
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:37 GMT
I don't think your comment adds much to this discussion @eschwartz. It's still not clear to me why it's unreasonable for tools to assume that package installations reproduce the structure offered by the binary releases. It should be the canonical structure, and we should emulate it.
Comment by Johan Brandhorst (jbrandhorst) - Monday, 22 October 2018, 20:38 GMT
@Foxboron, what are you basing that assertion on? The output of `./make.bash`?

Loading...