1 |
On Thu, 13 Feb 2014 11:59:16 -0600 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> Hi all, |
5 |
> |
6 |
> I responded to this a while back, but I guess my email didn't go out |
7 |
> for some reason. |
8 |
> |
9 |
> As the primary go maintainer, I do want to be involved in this. :-) |
10 |
> |
11 |
> On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote: |
12 |
> > On Mon, 30 Dec 2013 15:48:17 -0500 |
13 |
> > Emery Hemingway <emery@×××××××.net> wrote: |
14 |
> > |
15 |
> > > I really like working with Go, and would like to see a means of |
16 |
> > > merging Go packages with Portage. In short I am asking if anyone |
17 |
> > > else is interested in a Go project. |
18 |
> > |
19 |
> > I might be. I have packaged something for private use but it just a |
20 |
> > bunch of hacks. Anyway, I have some production go code. |
21 |
> > |
22 |
> > > |
23 |
> > > For those who aren't familiar with Go, I will sumarise why |
24 |
> > > Portage and Go do not play well together. |
25 |
> > > |
26 |
> > > Go is static linked by default. |
27 |
> > > The Go compiler creates static libraries and binaries. Libraries |
28 |
> > > compilied with different versions of Go (1.1/1.2) may not be |
29 |
> > > linked into the same binary. |
30 |
> > |
31 |
> > Haskell is staticaly linked as well (by default) and you can see the |
32 |
> > gentoo haskell project. I don't see this as a problem, we just will |
33 |
> > have all dependencies in DEPEND and will have to scope on the go |
34 |
> > compiler version under something like /usr/lib/go-1.{1,2}/... |
35 |
> |
36 |
> That could be done easily enough, but what about the tools in /usr/bin |
37 |
> (there aren't many, but there are a couple), and these do not change |
38 |
> name with each version of go. |
39 |
|
40 |
Please see what python does for different python versions (which you |
41 |
omitted from my previous email). |
42 |
|
43 |
> > > Go libraries are usually unversioned. |
44 |
> > > Libraries outside the system library are resolved with an import |
45 |
> > > statement that specifies a source code repository, such as a git |
46 |
> > > or mecurial repository. Most often Go libraries are installed |
47 |
> > > using the 'go get' tool that clones a repository, and simply |
48 |
> > > assumes HEAD/tip is the best revision to build against. There is |
49 |
> > > some support for using git tags but it is not well documented. |
50 |
> > > Often these libraries are very small for the sake of reuse and to |
51 |
> > > keep APIs simple. |
52 |
> |
53 |
> My understanding is that a library repo will have branches based on |
54 |
> the version of go, so for example, it might have a branch called go-1 |
55 |
> which will be where go get will look to find the latest version of |
56 |
> the code that works with go-1.x. |
57 |
> |
58 |
> > In this case we just have to require upstream to make releases or |
59 |
> > publish either live ebuilds, or ebuilds versioned something like |
60 |
> > 0_preYYYY-MM-DD.ebuild [1] |
61 |
> |
62 |
> I don't think we are going to be able to require upstream to make |
63 |
> releases, so that leaves us with: |
64 |
> |
65 |
> 1) using live ebuilds, which will never be allowed to have keywords by |
66 |
> gentoo policy, or |
67 |
> 2) publishing snapshots, which also means we have to create tarballs |
68 |
> to match them. This will be a lot of work for us as maintainers. |
69 |
> Also, the only way we will know when a new "version" of the library |
70 |
> is released is to closely monitor the upstream git repository. |
71 |
|
72 |
As I said in previous email, I think at least part of go community sees |
73 |
this as an issue and this is something we can not solve right now but |
74 |
rather need to work on this on case-by-case basis. |
75 |
|
76 |
Some upstreams may be willing to do releases / follow semver.org or |
77 |
something like that. But there will also be upstream which won't and |
78 |
that's fine, we should be able to handle both cases. |
79 |
|
80 |
Anyway, asking the upstream to do a release is simple enough and you |
81 |
won't know until you ask. |
82 |
|
83 |
> The other concern, which I believe zero was talking about is, once a |
84 |
> library is installed in GOPATH, I don't think the go build system |
85 |
> rebuilds it. In other words, "go get" will see that it is already |
86 |
> there and I don't think it goes back out to the net to check for any |
87 |
> changes. |
88 |
|
89 |
I think when doing a `go build` it will check if newer version is |
90 |
available and print a warning. |
91 |
|
92 |
> William |
93 |
> |
94 |
|
95 |
|
96 |
|
97 |
-- |
98 |
Jan Matějka | Gentoo Developer |
99 |
https://gentoo.org | Gentoo Linux |
100 |
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B |