1 |
On Fri, 14 Feb 2014 17:13:27 -0600 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote: |
5 |
> > On Fri, 14 Feb 2014 13:30:10 +0100 |
6 |
> > Jan Matejka <yac@g.o> wrote: |
7 |
> > |
8 |
> > > On Thu, 13 Feb 2014 11:59:16 -0600 |
9 |
> > > William Hubbs <williamh@g.o> wrote: |
10 |
> > > |
11 |
> > > > Hi all, |
12 |
> > > > |
13 |
> > > > I responded to this a while back, but I guess my email didn't |
14 |
> > > > go out for some reason. |
15 |
> > > > |
16 |
> > > > As the primary go maintainer, I do want to be involved in |
17 |
> > > > this. :-) |
18 |
> > > > |
19 |
> > > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote: |
20 |
> > > > > On Mon, 30 Dec 2013 15:48:17 -0500 |
21 |
> > > > > Emery Hemingway <emery@×××××××.net> wrote: |
22 |
> > > > > |
23 |
> > > > > > I really like working with Go, and would like to see a |
24 |
> > > > > > means of merging Go packages with Portage. In short I am |
25 |
> > > > > > asking if anyone else is interested in a Go project. |
26 |
> > > > > |
27 |
> > > > > I might be. I have packaged something for private use but it |
28 |
> > > > > just a bunch of hacks. Anyway, I have some production go code. |
29 |
> > > > > |
30 |
> > > > > > |
31 |
> > > > > > For those who aren't familiar with Go, I will sumarise why |
32 |
> > > > > > Portage and Go do not play well together. |
33 |
> > > > > > |
34 |
> > > > > > Go is static linked by default. |
35 |
> > > > > > The Go compiler creates static libraries and binaries. |
36 |
> > > > > > Libraries compilied with different versions of Go (1.1/1.2) |
37 |
> > > > > > may not be linked into the same binary. |
38 |
> > > > > |
39 |
> > > > > Haskell is staticaly linked as well (by default) and you can |
40 |
> > > > > see the gentoo haskell project. I don't see this as a |
41 |
> > > > > problem, we just will have all dependencies in DEPEND and |
42 |
> > > > > will have to scope on the go compiler version under something |
43 |
> > > > > like /usr/lib/go-1.{1,2}/... |
44 |
> > > > |
45 |
> > > > That could be done easily enough, but what about the tools |
46 |
> > > > in /usr/bin (there aren't many, but there are a couple), and |
47 |
> > > > these do not change name with each version of go. |
48 |
> > > |
49 |
> > > Please see what python does for different python versions (which |
50 |
> > > you omitted from my previous email). |
51 |
> |
52 |
> I omitted it, because thinking about it, we don't need to worry about |
53 |
> this. There isn't a reason you would want go 1.1 and go 1.2 on your |
54 |
> system. Source level compatibility is guaranteed for all go1 programs |
55 |
> [1]. |
56 |
> |
57 |
> > I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm |
58 |
> > working on an eselect module to manage the symlink to |
59 |
> > usr/bin/[go,gofmt] |
60 |
> |
61 |
> I would just install to /usr/lib/go1 and not worry about the eselect |
62 |
> module; there should not be a need to keep several versions of go1 |
63 |
> around, again, because go1.x releases will be source compatible. |
64 |
> |
65 |
> We could even just leave this as /usr/lib/go, because upstream doesn't |
66 |
> even know if a go-2 specification will happen. |
67 |
> |
68 |
> > The default GOROOT that go looks at for base libraries seems to be |
69 |
> > compiled in so this should be pretty easy, like python but simplier. |
70 |
> |
71 |
> It looks for standard libraries in GOROOT_FINAL which is set in the |
72 |
> ebuild and compiled into the binaries. |
73 |
> |
74 |
> Third party libraries are interesting in this case, because, all of |
75 |
> the third party libraries we install will not be usable once the user |
76 |
> upgrades from say go-1.2 to go-1.3. However, rebuilding those |
77 |
> libraries from source will work. |
78 |
> |
79 |
> William |
80 |
> |
81 |
> [1] http://golang.org/doc/go1compat |
82 |
|
83 |
The reason I thought go should be slotting was that all compliled |
84 |
libraries would break when go was replaced. |
85 |
|
86 |
Mabye the only the library source could be installed, and a cache of |
87 |
compiled libraries could be overlayed over that... |