Comment 1:

Labels changed: added documentation.

Comment 3:

a big problem is that: users of binary distributions might need root privilege to update
godoc and vet.

Comment 4:

They would have needed such privileges in the first place.
My concern is this:
$ cd /usr/local
$ sudo tar xzf go.tar.gz
$ export GOPATH=$HOME
$ sudo go get code.google.com/p/go.tools/cmd/{cover,godoc,vet}
This installs the tools to /usr/local/bin, but now $GOPATH/{src,pkg} contain a bunch of
source and object files that are owned by root. :-/
We could potentially fix this by forcing it to be a two part process. Where "go get"
detects refuses to download source and write package objects as the superuser. For
instance:
$ sudo go get code.google.com/p/go.tools/cmd/{cover,godoc,vet}
Cannot "go get" as root.
So then the user would try:
$ go get code.google.com/p/go.tools/cmd/{cover,godoc,vet}
Can't write to /usr/local/go/bin.
$ sudo go get code.google.com/p/go.tools/cmd/{cover,godoc,vet}
Success, because all this does is build the binaries and cp them to /usr/local/go/bin.
The source has been fetched and the dependent packages have been compiled by the
previous invocation. 
Maybe there's a bigger picture here involving the standard library and the -a flag, too.
The main question is: do we want to make the go tool behave differently when executed by
a superuser?

Comment 5:

yeah, that is my concern too.
i wonder if we could just support installing godoc and vet to GOPATh/bin?
the one in the default location could look for those in GOPATH,
and exec them if found.

Comment 6:

No, we definitely do not want the go command to behave differently when executed by
root. Don't second guess what people ask it to do.
The shell transcript you gave is no different than running make && make install as root
in a non-Go program's installation. You end up with files owned by root. So don't do
that. 
If the user tries
$ cd /usr/local
$ sudo tar xzf go.tar.gz
$ export GOPATH=$HOME
$ sudo go get code.google.com/p/go.tools/cmd/{cover,godoc,vet}
then I think they deserve what they get. We can't help people who don't understand how
to be root. Why are they updating just those three programs? Why are those different
from gofmt? I really don't understand the problem being solved here.
I thought this bug was about telling people who build from source how to get those
programs, since they otherwise would not. 
And in that case I think the answer is you run the 'go get -u
code.google.com/p/go.tools/cmd/cover' and then again for godoc and vet (cannot use { }
syntax because it doesn't work in all shells, notably Windows).

Comment 7:

I suppose it is reasonable to assume that people who install from source should
understand how root works, and that people who install with binary distributions need
not update godoc, vet, or cover until they install the next binary release.
We should, however, document the installation of godoc, cover, and vet in the source
installation instructions.

Comment 8:

Owner changed to @adg.

Comment 9:

This issue was closed by revision b3caa86.

Status changed to Fixed.