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