[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Go (golang) packaging, part 2

Hi Hilko,

Hilko Bengen <bengen@debian.org> 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
> entry.
> 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.

Best regards,

Reply to: