1 |
On Fri, Jun 12, 2015 at 11:18:29AM -0700, Patrick McLean wrote: |
2 |
> On Fri, 12 Jun 2015 12:54:04 -0500 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
> > All, |
6 |
> > |
7 |
> > in looking at some of the Go ebuilds we have in the tree, I see that |
8 |
> > some of them, for example go-tools, have multiple Go packages in a |
9 |
> > single repository. This means that something like: |
10 |
> > |
11 |
> > go get -d -u -t golang.org/x/tools |
12 |
> > |
13 |
> > will fail. There is an issue opened upstream about this [1]. |
14 |
> > |
15 |
> > My question for this list is, should we wait for this to be resolved |
16 |
> > before we do anything, or should we change the go packaging we are |
17 |
> > doing to package single go packages instead of repositories? |
18 |
> |
19 |
> I would vote for packaging separate packages as we do for other |
20 |
> languages. |
21 |
|
22 |
Ok, I'm with you here. |
23 |
|
24 |
> We could make go ebuilds simply install their sources to |
25 |
> something like /usr/share/go/${PN}-${SLOT}. Then have an eclass build |
26 |
> GOPATH from the installation paths of all the dependencies of that |
27 |
> package. All go libraries should have subslots that match ${PV}, and go |
28 |
> packages should use slot operator deps to make sure they get rebuild |
29 |
> when a library gets updated. |
30 |
> |
31 |
> AFAIK this is the only way to get sane and predictable dependency |
32 |
> behaviour with go packages, since upstream seems to be think dynamic |
33 |
> linking is evil. |
34 |
|
35 |
This brings up a whole new question which is sort of confusing to me. |
36 |
|
37 |
Ebuilds like go-net, and some others that are in the tree, do not build |
38 |
executables. They only build *.a files which are used at build time by |
39 |
other pure go consumers. Also, there are no upstream releases for these |
40 |
types of packages most of the time. |
41 |
|
42 |
Since the Go compiler bundles all the necessary packages to compile a go |
43 |
binary, I can't help but wonder if we really need manual snapshots of |
44 |
packages that build only *.a files in the tree? |
45 |
|
46 |
Thoughts? |
47 |
|
48 |
William |