Re: Go (golang) packaging, part 2
Michael,
after re-reading your GoPackaging Wiki page and digging around a bit in
the sources for the go tool, I think that only minimal changes to go(1)
are needed for its build system to "Just Work" without breaking
expectations:
1. Debian user's/admin's perspective: As I have already written
elsewhere in this thread, using upstream build systems without extra
parameters usually results in libraries and binaries being installed to
/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.
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.
2. Software developer's perspective: Since the text "How to Write Go
Code" at http://golang.org/doc/code.html tells me right away that
setting GOPATH is something I need to do, changing the GOPATH default
value should not cause too much confusion.
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.
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?
Cheers,
-Hilko
Reply to: