Re: Go (golang) packaging, part 2

[Hilko Bengen <bengen@debian.org>]

* Michael Stapelberg:

> 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?

Right. Anf if I have interpreted the code correctly, "go get -u
<package>" will at the moment try to update the first occurence of the
package that it finds in $GOROOT or $GOPATH.

>> 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.

Maybe they can also be persuaded to put the two roles that have been
assigned to GOPATH into separate variables: A search path and an
installation target.

>> 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? :-)

I may have misunderstood what you meant with "used directly for Go
development". Ah well, let me try again: I would very much like to see a
number of useful Go library packages distributed by Debian that:

- make the process for developing or building executables (and other
  libraries) as easy as or easier than using "go get". (This is what I
  understand as direct usage.)

- make it possible and easy to package such executables and libraries
  for Debian. Specific DBMS support packages for the database/sql
  interface come to mind...

I agree with putting libraries into a directory separate from $GOROOT
because I consider it the lesser evil as long as the go(1) questions
aren't sorted out.

>> 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.

To get things started with as little effort as possible, pick one
compiler and package some libraries and executable packages, such as
codesearch. I'm all in favor of this compiler being golang-go.

It will also make sense to support gccgo[1] at some point -- if only for
portability across all Debian platforms. Picking an extensible naming
scheme directory hierarchy (such as /usr/lib/gocode/$IMPL) would make
this possible from the start.

By the way: Where does the idea for the "gocode" directory name come
from?

Cheers,
-Hilko

[1] and possibly other implementations that may come with yet different
incompatible binary interfaces...