Re-building standard library packages with a read-only GOROOT

920 views
Skip to first unread message

Michael Hudson-Doyle

unread,
Apr 25, 2016, 8:12:41 PM4/25/16
to golang-dev
Hi all,

There are a few bugs in Debian (and now also golang.org/issue/15433)
where go install commands that want to recompile standard packages
(for example, -buildmode=pie or cross-building) fail because GOROOT is
read-only.

This is all perfectly understandable but it's not a good user
experience. I don't really know what would be the best option.

We could tell everyone to use the "go build" version of the same
commands succeeds, but obviously that rebuilds everything every time.
In a vaguely similar vein we could ignore permission denied errors
trying to install a package where p.Standard == true.

Having GOROOT be writable by all users seems like a _really_ bad idea.

Having some kind of per user GOROOT that's a symlink tree pointing at
the deb-installed one or an overlayfs over the deb-installed one
sounds more appealing but I'm not really sure how to implement it.

Does anyone have any other ideas for how to handle this that I haven't
thought of?

Cheers,
mwh

Russ Cox

unread,
Apr 25, 2016, 8:48:42 PM4/25/16
to Michael Hudson-Doyle, golang-dev
I think you can use -pkgdir. See https://go-review.googlesource.com/12171 and https://golang.org/issue/10210 (which the CL fixed).

Russ

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Benny Siegert

unread,
Apr 26, 2016, 4:57:40 AM4/26/16
to Russ Cox, Michael Hudson-Doyle, golang-dev
In pkgsrc, we address this issue with the buildlink framework that's part of its infrastructure. When building Go code, we create a symlink tree Goliath containing the standard library plus any declared dependencies. This way, recompiles just replace the symlink (which will be cleared on make
Clean anyway), and you can enforce the package to correctly declare dependencies.

Michael Hudson-Doyle

unread,
Apr 26, 2016, 6:06:57 AM4/26/16
to Russ Cox, golang-dev
Ah, thanks. That's a fine suggestion for the interactive use cases,
and probably even for the build-system ones too (with some symlinks
per Benny's suggestion).

Cheers,
mwh
Reply all
Reply to author
Forward
0 new messages