Skip to content
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: install -a fails if GOROOT is not writeable #5065

Closed
4a6f656c opened this issue Mar 17, 2013 · 2 comments
Closed

cmd/go: install -a fails if GOROOT is not writeable #5065

4a6f656c opened this issue Mar 17, 2013 · 2 comments

Comments

@4a6f656c
Copy link
Contributor

Currently 'go install -a' fails when run for packages under GOPATH, if the GOROOT is not
writeable:

$ sudo tar -C /usr/local -xzf go1.0.3.linux-amd64.tar.gz
$ echo $GOPATH
/home/jsing/src/mygo
$ go install -a example
go install runtime: open /usr/local/go/pkg/linux_amd64/runtime.a: permission denied

Obviously '-a' means all, however it would be useful if we could force a rebuild for all
of the dependencies under the GOPATH only (or skip dependencies in GOROOT).
@adg
Copy link
Contributor

adg commented Mar 18, 2013

Comment 1:

I think this should wait until after Go 1.1.

Labels changed: added priority-later, removed priority-triage.

@rsc
Copy link
Contributor

rsc commented Mar 19, 2013

Comment 2:

I don't want to make the pattern language more complex. You can already do
cd $GOPATH
go install ./...

Status changed to WorkingAsIntended.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
gopherbot pushed a commit that referenced this issue Dec 6, 2017
This CL makes "go install" behave the way many users expect:
install only the things named on the command line.
Future builds still run as fast, thanks to the new build cache (CL 75473).
To install dependencies as well (the old behavior), use "go install -i".

Actual definitions aside, what most users know and expect of "go install"
is that (1) it installs what you asked, and (2) it's fast, unlike "go build".
It was fast because it installed dependencies, but installing dependencies
confused users repeatedly (see for example #5065, #6424, #10998, #12329,
"go build" and "go test" so that they could be "fast" too, but that only
created new opportunities for confusion. We also had to add -installsuffix
and then -pkgdir, to allow "fast" even when dependencies could not be
installed in the usual place.

The recent introduction of precise content-based staleness logic means that
the go command detects the need for rebuilding packages more often than it
used to, with the consequence that "go install" rebuilds and reinstalls
dependencies more than it used to. This will create more new opportunities
for confusion and will certainly lead to more issues filed like the ones
listed above.

CL 75743 introduced a build cache, separate from the install locations.
That cache makes all operations equally incremental and fast, whether or
not the operation is "install" or "build", and whether or not "-i" is used.

Installing dependencies is no longer necessary for speed, it has confused
users in the past, and the more accurate rebuilds mean that it will confuse
users even more often in the future. This CL aims to end all that confusion
by not installing dependencies by default.

By analogy with "go build -i" and "go test -i", which still install
dependencies, this CL introduces "go install -i", which installs
dependencies in addition to the things named on the command line.

Fixes #5065.
Fixes #6424.
Fixes #10998.
Fixes #12329.
Fixes #18981.
Fixes #22469.

Another step toward #4719.

Change-Id: I3d7bc145c3a680e2f26416e182fa0dcf1e2a15e5
Reviewed-on: https://go-review.googlesource.com/75850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants