On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
> On Fri, 14 Feb 2014 13:30:10 +0100
> Jan Matejka <yac@gentoo.org> wrote:
> 
> > On Thu, 13 Feb 2014 11:59:16 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > Hi all,
> > > 
> > > I responded to this a while back, but I guess my email didn't go out
> > > for some reason.
> > > 
> > > As the primary go maintainer, I do want to be involved in this. :-)
> > > 
> > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > > > On Mon, 30 Dec 2013 15:48:17 -0500
> > > > Emery Hemingway <emery@vfemail.net> wrote:
> > > > 
> > > > > I really like working with Go, and would like to see a means of
> > > > > merging Go packages with Portage. In short I am asking if anyone
> > > > > else is interested in a Go project.
> > > > 
> > > > I might be. I have packaged something for private use but it just
> > > > a bunch of hacks. Anyway, I have some production go code.
> > > > 
> > > > >
> > > > > For those who aren't familiar with Go, I will sumarise why
> > > > > Portage and Go do not play well together.
> > > > >
> > > > > Go is static linked by default.
> > > > > The Go compiler creates static libraries and binaries. Libraries
> > > > > compilied with different versions of Go (1.1/1.2) may not be
> > > > > linked into the same binary.
> > > > 
> > > > Haskell is staticaly linked as well (by default) and you can see
> > > > the gentoo haskell project. I don't see this as a problem, we
> > > > just will have all dependencies in DEPEND and will have to scope
> > > > on the go compiler version under something
> > > > like /usr/lib/go-1.{1,2}/...
> > > 
> > > That could be done easily enough, but what about the tools
> > > in /usr/bin (there aren't many, but there are a couple), and these
> > > do not change name with each version of go.
> > 
> > Please see what python does for different python versions (which you
> > omitted from my previous email).

I omitted it, because thinking about it, we don't need to worry about
this. There isn't a reason you would want go 1.1 and go 1.2 on your
system. Source level compatibility is guaranteed for all go1 programs
[1].

> I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
> working on an eselect module to manage the symlink to usr/bin/[go,gofmt]

I would just install to /usr/lib/go1 and not worry about the eselect
module; there should not be a need to keep several versions of go1
around, again, because go1.x releases will be source compatible.

We could even just leave this as /usr/lib/go, because upstream doesn't
even know if a go-2 specification will happen.

> The default GOROOT that go looks at for base libraries seems to be
> compiled in so this should be pretty easy, like python but simplier.

It looks for standard libraries in GOROOT_FINAL which is set in the
ebuild and compiled into the binaries.

Third party libraries are interesting in this case, because, all of the
third party libraries we install will not be usable once the user
upgrades from say go-1.2 to go-1.3. However, rebuilding those libraries
from source will work.

William

[1] http://golang.org/doc/go1compat