Re: [gentoo-dev] dev-lang/go

[yac]

On Fri, 14 Feb 2014 11:02:49 -0500
Emery Hemingway <emery@×××××××.net> wrote:

> On Fri, 14 Feb 2014 13:30:10 +0100
> Jan Matejka <yac@g.o> wrote:
>
> > On Thu, 13 Feb 2014 11:59:16 -0600
> > William Hubbs <williamh@g.o> 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@×××××××.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'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]
>
> 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.

I'm not sure what you are trying to solve here. Afaik GOROOT is used to
determine where to install and it can be overriden from env.

> An eclass could look at a GO_MINIMUM variable and install for each
> version go that is present and matches.

It might be good idea to learn from others who'd been through this and
I think the new python eclasses are good ones, going with something
like PYTHON_TARGETS array (GOLANG_TARGETS ?)

> Dropping old versions of go
> will be easy because linking wont break, and new releases should be
> forwards compatible.

So far yes I think but I guess that may be quite different with in the
future with >1.x, and "should be" so there may be corner cases where the
user does need to use earlier version.

> Maybe 3rd party library sources could be stored
> in a version agnostic directory and symlinked in to
> usr/lib/goX.X/gentoo to deduplicate the files?

I'm not sure this is a good idea either. Disk space is cheap and 
doing this would only require adding special case handling code which
would get even more complicated when doing upgrades or the situation
changes (eg. main golang version).

Also keep in mind, the main golang version should not be just "1.1" but
rather "go1.1" as you may also want to choose "gcc<something>".

> > > > > 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.
> >
> > As I said in previous email, I think at least part of go community
> > sees this as an issue and this is something we can not solve right
> > now but rather need to work on this on case-by-case basis.
> >
> > Some upstreams may be willing to do releases / follow semver.org or
> > something like that. But there will also be upstream which won't and
> > that's fine, we should be able to handle both cases.
> >
> > Anyway, asking the upstream to do a release is simple enough and you
> > won't know until you ask.
> >
> > > 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.
> >
> > I think when doing a `go build` it will check if newer version is
> > available and print a warning.
> >
> We may have to make some sort of utitilty to parse sources and check
> for updates, and roll tarballs to mirror.
> >
> > > William
> > >
> >
> >
> >
> > --
> > Jan Matějka        | Gentoo Developer
> > https://gentoo.org | Gentoo Linux
> > GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
>
>



---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B