1 |
On Mon, 30 Dec 2013 15:48:17 -0500 |
2 |
Emery Hemingway <emery@×××××××.net> wrote: |
3 |
|
4 |
> I really like working with Go, and would like to see a means of |
5 |
> merging Go packages with Portage. In short I am asking if anyone else |
6 |
> is interested in a Go project. |
7 |
|
8 |
I might be. I have packaged something for private use but it just a |
9 |
bunch of hacks. Anyway, I have some production go code. |
10 |
|
11 |
> |
12 |
> For those who aren't familiar with Go, I will sumarise why Portage and |
13 |
> Go do not play well together. |
14 |
> |
15 |
> Go is static linked by default. |
16 |
> The Go compiler creates static libraries and binaries. Libraries |
17 |
> compilied with different versions of Go (1.1/1.2) may not be linked |
18 |
> into the same binary. |
19 |
|
20 |
Haskell is staticaly linked as well (by default) and you can see the |
21 |
gentoo haskell project. I don't see this as a problem, we just will have |
22 |
all dependencies in DEPEND and will have to scope on the go compiler |
23 |
version under something like /usr/lib/go-1.{1,2}/... |
24 |
|
25 |
I'd just copy the python herd approach (use flags, filesystem scoping |
26 |
and having binary wrapper). |
27 |
|
28 |
> It is possible to compile dynamicly and that may involve using the |
29 |
> GCC frontend, which is probably less tested and less optimized. |
30 |
|
31 |
I'd just skip over this unless someone is really interested in this one, |
32 |
in which case this could be explicitly enabled by a use flag or |
33 |
something. |
34 |
|
35 |
> |
36 |
> Go libraries are usually unversioned. |
37 |
> Libraries outside the system library are resolved with an import |
38 |
> statement that specifies a source code repository, such as a git or |
39 |
> mecurial repository. Most often Go libraries are installed using the |
40 |
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is |
41 |
> the best revision to build against. There is some support for using |
42 |
> git tags but it is not well documented. Often these libraries are very |
43 |
> small for the sake of reuse and to keep APIs simple. |
44 |
|
45 |
In this case we just have to require upstream to make releases or |
46 |
publish either live ebuilds, or ebuilds versioned something like |
47 |
0_preYYYY-MM-DD.ebuild [1] |
48 |
|
49 |
I know part of the gopher commnity doesn't see this as a problem but I |
50 |
believe the big players recognize this and there is an effort to come up |
51 |
with a solution. |
52 |
|
53 |
> If all that sounds bad, thats because it is. Is it worth versioning |
54 |
> many tiny libraries or do we simply cache the repositiories and blame |
55 |
> upstream when things stop compiling? |
56 |
|
57 |
I'd certainly want to have versions where available. |
58 |
|
59 |
> |
60 |
> A have made an eclass for Go and an ebuild for the bitcoin node |
61 |
> written in pure Go to atleast prove that all this is possible. These |
62 |
> are in the 'emery' overlay: |
63 |
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass |
64 |
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go |
65 |
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd |
66 |
> |
67 |
> The eclass it a bit of a mess but it works, having done that, I would |
68 |
> say that making ebuilds for every go library is tedious, but can be |
69 |
> done almost entirely with boilerplate, almost every time. |
70 |
> |
71 |
> The eclasss installs go source and static libraries |
72 |
> to /usr/lib/go/gentoo (source code and .a library are required to |
73 |
> link). The problem is when Go is updated, this folder may get wiped |
74 |
> out, and if it isn't, those libraries will be incompatable with the |
75 |
> new release anyway. |
76 |
|
77 |
How come it gets wiped? That just shouldn't happen. |
78 |
|
79 |
> The other solution I see is to make a Go directory in /var/cache or |
80 |
|
81 |
I don't think this is a good idea as I think it would be surprising to |
82 |
users to find libraries elsewhere than /usr/lib and I believe /var/cache |
83 |
specificaly even violates FHS. |
84 |
|
85 |
> something like it and just manage it as a cache. |
86 |
> Libraries may come and go but that is fine. |
87 |
|
88 |
I might want to have a library just for development and I'd wouldn't |
89 |
like it disappearing. |
90 |
|
91 |
> Bare repositories may be cached in DISTDIR |
92 |
> just like the git and mercurial eclasses do. Doing things this way may |
93 |
> require a specific utility for Portage that wraps the Go toolchain, |
94 |
> which I would be willing to create. This utility could probably |
95 |
> automatically resolve and fetch the libraries that are required |
96 |
|
97 |
Building the library/package shouldn't/mustn't (what does the PMS |
98 |
say?) require network access once the sources are fetched. |
99 |
|
100 |
> as opposed to making an ebuild for each library, but that raises the |
101 |
> problem of assuming the developers of each library maintain consistant |
102 |
> quality and security. |
103 |
|
104 |
Every ebuild that gets to gentoo official must meet basic standard of |
105 |
quality. That's no different for golang. |
106 |
|
107 |
> |
108 |
> |
109 |
> The problem is Go makes it trivial to build from source, but it does |
110 |
> that in a very different and less precise way than Gentoo. There is |
111 |
> always the option of build bots and installing binaries to /opt... |
112 |
> |
113 |
> |
114 |
> Emery |
115 |
> |
116 |
|
117 |
I think it would be good idea to start a separate gentoo-golang |
118 |
repository (github?) and treat it more (to keep it aligned with the way |
119 |
gentoo works) or less (to speed up the development) as if it were gx86. |
120 |
|
121 |
In the organization part, I think we could inspire ourself in the way |
122 |
gentoo-haskell works. |
123 |
|
124 |
[1]: http://devmanual.gentoo.org/ebuild-writing/file-format/ |
125 |
|
126 |
--- |
127 |
Jan Matějka | Gentoo Developer |
128 |
https://gentoo.org | Gentoo Linux |
129 |
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B |