Re: Go (golang) packaging, part 2
Hilko Bengen <email@example.com> writes:
> /usr/local. This is not what "sudo go get" currently (version 1:1.0.2-2)
> does -- it happily puts both source and binary files into GOROOT
> (=/usr/lib/go). This is bound to break things in interesting ways at
> some point.
Indeed. This is when having an empty GOPATH, right?
> One way to fix this would be changing the default GOPATH setting from an
> empty string to a path that has "/usr/local/lib/go" as its first
> Another quick solution might be changing go(1)'s behavior so that it
> will still look for libraries in GOROOT, just not attempt to modify
> files there.
I prefer the latter. We should ask upstream about their point of view on
this first, though.
> 3. Debian package maintainer's perspective: I disagree with your
> position that "Go libraries [...] should not be used directly for Go
> development". If I put together a Debian package for a Go library,
> developers should still have the option to use it. And it should be
> easy, preferably be installed into the default GOPATH, so a second entry
> (after /usr/local/lib/go) does not seem unreasonable.
> Upstream has not made it clear whether 3rd partylibraries should be
> installed into GOROOT or somewhere else. There still are a few
> unanswered questions about how go(1) should behave, and what bugs are
> still lurking in that code. Perhaps upstream will change go(1) so that a
> concept of third-party libraries is possible. Until then, putting
> libraries into a separate directory such as /usr/lib/gocode seems like a
> good idea.
I am slightly confused. First you say you disagree, but then you admit
that there still are problems and agree with regards to placing
libraries into /usr/lib/gocode after all? :-)
> But what about gccgo? Apparently, go(1) can be used with gccgo, but
> gccgo-compiled code cannot be linked with golang-go-compiled code. So,
> perhaps it makes sense to install the libraries produced by each
> compiler into separate directory hierarchies -- /usr/lib/gocode/golang
> and /usr/lib/gocode/gccgo?
I’d say it makes more sense to pick one compiler instead.