On Monday 07 December 2015 23:31:34 Stuart Henderson wrote: > On 2015/12/08 10:05, Joel Sing wrote: > > On Monday 07 December 2015 14:18:52 Kent R. Spillner wrote: > > > On Tue, Dec 08, 2015 at 02:29:03AM +1100, Joel Sing wrote: > > > > This brings me to the next issue/topic - installing additional > > > > packages > > > > under /usr/local/go is probably a bad idea. > > > > > > My recollection is that the other issues you mentioned were necessary in > > > order to make this work. So if everyone agrees to a fix for this then I > > > believe the others just go away. > > > > > > > There are likely two options - we could install packages in a separate > > > > location (e.g. /usr/local/go-pkg) and then when code is built it is > > > > added > > > > to GOPATH. Alternatively, the code is fetched and built when the > > > > binary > > > > is built > > > > > > I think option #1 (install packages in a separate location and then add > > > it > > > to GOPATH) is our only choice because ports shouldn't fetch anything > > > during > > > builds. > > > > I was moreso thinking along the lines of using 'go get -d' to fetch the > > sources, > > This is the main problem that go.port.mk was trying to solve - file fetching > is done by ports infrastructure, not by the port itself. In the bulk build > case, this is totally under control of DPB which calls out to ftp(1) to > fetch as a separate uid, and DPB checks the hash itself - the port Makefile > is only used to fetch the filename/url. > > The uid running the actual port build doesn't have network privileges.
Thanks for clarlifying - we could still implement 'go get -d' as a way of getting sources, but it would be more work than it is likely worth (and there are also some issues surrounding which versions of the dependencies get fetched). I'll rework go.port.mk and the relevant packages using /usr/local/go-pkg.
