1 |
All, |
2 |
|
3 |
I want to start a discussion here about the go ebuilds we have in the |
4 |
tree that are installing *.a files to $GOROOT/pkg. From now on in this |
5 |
message, when I say package, I mean a *.a file. |
6 |
|
7 |
dev-lang/go must do this, because it includes the standard library. |
8 |
However, I do not think third party programs written in go should put |
9 |
their packages there, or maybe anywhere at all, for a couple of reasons. |
10 |
|
11 |
First, the format of Go's packages is not guaranteed to be the same for |
12 |
new releases of Go; only source level compatibility is guaranteed [1]. |
13 |
This means every thircd party Go package should be rebuilt every time |
14 |
dev-lang/go is bumped. I thought about subslotting dev-lang/go, but |
15 |
given the second consideration, that seems to be a lot of overhead |
16 |
without a good reason unless I am missing something. |
17 |
|
18 |
The second consideration is that go's packages are static; they are only |
19 |
used at build time. Once you have a go binary compiled, you do not need |
20 |
any external libraries to run the binary, and normally in Gentoo, we do |
21 |
not keep static libraries around. |
22 |
|
23 |
These considerations, combined with how "go get" pulls all dependencies |
24 |
of a project, lead me to wonder if we should have ebuilds in the tree |
25 |
for Go projects that only install packages. |
26 |
|
27 |
I'm interested in hearing what people think. |
28 |
|
29 |
William |
30 |
|
31 |
[1] https://golang.org/doc/go1compat |