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.
> > Go libraries are usually unversioned.
> > Libraries outside the system library are resolved with an import
> > statement that specifies a source code repository, such as a git or
> > mecurial repository. Most often Go libraries are installed using the
> > 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> > the best revision to build against. There is some support for using
> > git tags but it is not well documented. Often these libraries are very
> > small for the sake of reuse and to keep APIs simple.
My understanding is that a library repo will have branches based on the
version of go, so for example, it might have a branch called go-1 which
will be where go get will look to find the latest version of the code
that works with go-1.x.
> In this case we just have to require upstream to make releases or
> publish either live ebuilds, or ebuilds versioned something like
> 0_preYYYY-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have keywords by
gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs to
match them. This will be a lot of work for us as maintainers. Also, the
only way we will know when a new "version" of the library is released is
to closely monitor the upstream git repository.
The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, "go get" will see that it is already there
and I don't think it goes back out to the net to check for any changes.
William
signature.asc
Description: Digital signature
