On Fri, 14 Feb 2014 17:13:27 -0600
William Hubbs <willi...@gentoo.org> wrote:
> On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
> > On Fri, 14 Feb 2014 13:30:10 +0100
> > Jan Matejka <y...@gentoo.org> wrote:
> >
> > > On Thu, 13 Feb 2014 11:59:16 -0600
> > > William Hubbs <willi...@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 <em...@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
The reason I thought go should be slotting was that all compliled
libraries would break when go was replaced.
Mabye the only the library source could be installed, and a cache of
compiled libraries could be overlayed over that...
