| 1 |
On Fri, 12 Jun 2015 12:54:04 -0500 |
| 2 |
William Hubbs <williamh@g.o> wrote: |
| 3 |
|
| 4 |
> All, |
| 5 |
> |
| 6 |
> in looking at some of the Go ebuilds we have in the tree, I see that |
| 7 |
> some of them, for example go-tools, have multiple Go packages in a |
| 8 |
> single repository. This means that something like: |
| 9 |
> |
| 10 |
> go get -d -u -t golang.org/x/tools |
| 11 |
> |
| 12 |
> will fail. There is an issue opened upstream about this [1]. |
| 13 |
> |
| 14 |
> My question for this list is, should we wait for this to be resolved |
| 15 |
> before we do anything, or should we change the go packaging we are |
| 16 |
> doing to package single go packages instead of repositories? |
| 17 |
|
| 18 |
I would vote for packaging separate packages as we do for other |
| 19 |
languages. We could make go ebuilds simply install their sources to |
| 20 |
something like /usr/share/go/${PN}-${SLOT}. Then have an eclass build |
| 21 |
GOPATH from the installation paths of all the dependencies of that |
| 22 |
package. All go libraries should have subslots that match ${PV}, and go |
| 23 |
packages should use slot operator deps to make sure they get rebuild |
| 24 |
when a library gets updated. |
| 25 |
|
| 26 |
AFAIK this is the only way to get sane and predictable dependency |
| 27 |
behaviour with go packages, since upstream seems to be think dynamic |
| 28 |
linking is evil. |
| 29 |
|
| 30 |
> Thanks, |
| 31 |
> |
| 32 |
> William |
| 33 |
> |
| 34 |
> [1] https://github.com/golang/go/issues/11090 |
Archives