1 |
Hi all, |
2 |
|
3 |
I responded to this a while back, but I guess my email didn't go out for |
4 |
some reason. |
5 |
|
6 |
As the primary go maintainer, I do want to be involved in this. :-) |
7 |
|
8 |
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote: |
9 |
> On Mon, 30 Dec 2013 15:48:17 -0500 |
10 |
> Emery Hemingway <emery@×××××××.net> wrote: |
11 |
> |
12 |
> > I really like working with Go, and would like to see a means of |
13 |
> > merging Go packages with Portage. In short I am asking if anyone else |
14 |
> > is interested in a Go project. |
15 |
> |
16 |
> I might be. I have packaged something for private use but it just a |
17 |
> bunch of hacks. Anyway, I have some production go code. |
18 |
> |
19 |
> > |
20 |
> > For those who aren't familiar with Go, I will sumarise why Portage and |
21 |
> > Go do not play well together. |
22 |
> > |
23 |
> > Go is static linked by default. |
24 |
> > The Go compiler creates static libraries and binaries. Libraries |
25 |
> > compilied with different versions of Go (1.1/1.2) may not be linked |
26 |
> > into the same binary. |
27 |
> |
28 |
> Haskell is staticaly linked as well (by default) and you can see the |
29 |
> gentoo haskell project. I don't see this as a problem, we just will have |
30 |
> all dependencies in DEPEND and will have to scope on the go compiler |
31 |
> version under something like /usr/lib/go-1.{1,2}/... |
32 |
|
33 |
That could be done easily enough, but what about the tools in /usr/bin |
34 |
(there aren't many, but there are a couple), and these do not change |
35 |
name with each version of go. |
36 |
|
37 |
> > Go libraries are usually unversioned. |
38 |
> > Libraries outside the system library are resolved with an import |
39 |
> > statement that specifies a source code repository, such as a git or |
40 |
> > mecurial repository. Most often Go libraries are installed using the |
41 |
> > 'go get' tool that clones a repository, and simply assumes HEAD/tip is |
42 |
> > the best revision to build against. There is some support for using |
43 |
> > git tags but it is not well documented. Often these libraries are very |
44 |
> > small for the sake of reuse and to keep APIs simple. |
45 |
|
46 |
My understanding is that a library repo will have branches based on the |
47 |
version of go, so for example, it might have a branch called go-1 which |
48 |
will be where go get will look to find the latest version of the code |
49 |
that works with go-1.x. |
50 |
|
51 |
> In this case we just have to require upstream to make releases or |
52 |
> publish either live ebuilds, or ebuilds versioned something like |
53 |
> 0_preYYYY-MM-DD.ebuild [1] |
54 |
|
55 |
I don't think we are going to be able to require upstream to make |
56 |
releases, so that leaves us with: |
57 |
|
58 |
1) using live ebuilds, which will never be allowed to have keywords by |
59 |
gentoo policy, or |
60 |
2) publishing snapshots, which also means we have to create tarballs to |
61 |
match them. This will be a lot of work for us as maintainers. Also, the |
62 |
only way we will know when a new "version" of the library is released is |
63 |
to closely monitor the upstream git repository. |
64 |
|
65 |
The other concern, which I believe zero was talking about is, once a |
66 |
library is installed in GOPATH, I don't think the go build system |
67 |
rebuilds it. In other words, "go get" will see that it is already there |
68 |
and I don't think it goes back out to the net to check for any changes. |
69 |
|
70 |
William |