On Fri, Jun 12, 2015 at 11:18:29AM -0700, Patrick McLean wrote: > On Fri, 12 Jun 2015 12:54:04 -0500 > William Hubbs <[email protected]> wrote: > > > All, > > > > in looking at some of the Go ebuilds we have in the tree, I see that > > some of them, for example go-tools, have multiple Go packages in a > > single repository. This means that something like: > > > > go get -d -u -t golang.org/x/tools > > > > will fail. There is an issue opened upstream about this [1]. > > > > My question for this list is, should we wait for this to be resolved > > before we do anything, or should we change the go packaging we are > > doing to package single go packages instead of repositories? > > I would vote for packaging separate packages as we do for other > languages.
Ok, I'm with you here.
> We could make go ebuilds simply install their sources to
> something like /usr/share/go/${PN}-${SLOT}. Then have an eclass build
> GOPATH from the installation paths of all the dependencies of that
> package. All go libraries should have subslots that match ${PV}, and go
> packages should use slot operator deps to make sure they get rebuild
> when a library gets updated.
>
> AFAIK this is the only way to get sane and predictable dependency
> behaviour with go packages, since upstream seems to be think dynamic
> linking is evil.
This brings up a whole new question which is sort of confusing to me.
Ebuilds like go-net, and some others that are in the tree, do not build
executables. They only build *.a files which are used at build time by
other pure go consumers. Also, there are no upstream releases for these
types of packages most of the time.
Since the Go compiler bundles all the necessary packages to compile a go
binary, I can't help but wonder if we really need manual snapshots of
packages that build only *.a files in the tree?
Thoughts?
William
signature.asc
Description: Digital signature
