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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4kyfp8s....@msgid.hilluzination.de
