1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 30/06/2015 05:25, Zac Medico wrote: |
5 |
> On 06/29/2015 07:24 PM, Michael Orlitzky wrote: |
6 |
>> On 06/29/2015 07:44 PM, Zac Medico wrote: |
7 |
>>> |
8 |
|
9 |
Having faced the exact same problem I have to say I agree 100% with |
10 |
Zac. I'd like to say that Gentoo needs this kind of packages to stay |
11 |
actual and that our NOGO (yes that's an actual joke) on Go packages is |
12 |
not good for us nowdays. |
13 |
|
14 |
>>> While it would certainly be possible to split out a number of |
15 |
>>> separate ebuilds for Go libraries that are used *exclusively* |
16 |
>>> by consul, what advantages would it have? |
17 |
>> |
18 |
>> Even in this limiting case, |
19 |
>> |
20 |
>> 1. You avoid pointless rebuilds. You rebuild the library (and |
21 |
>> probably the binary, for Go packages) when the library is |
22 |
>> upgraded rather than rebuilding everything whenever anything is |
23 |
>> updated. |
24 |
> |
25 |
> From my experience, Go packages don't take very long to build. |
26 |
> |
27 |
|
28 |
+1, Go is not C, I have the same feeling |
29 |
|
30 |
>> 2. Security. If upstream treats the packages as separate, a user |
31 |
>> might hear that there's a security issue in libfoo but then run |
32 |
>> eix and see that he doesn't have libfoo installed (because it's |
33 |
>> bundled). |
34 |
> |
35 |
> That's a reasonable motivation. However, many of these libraries |
36 |
> don't have any tags. So, you'll have to use the commit hashes if |
37 |
> you want to test for vulnerabilities. In the case of the consul |
38 |
> ebuild, the commit hashes of the libraries are available in the |
39 |
> SRC_URI. I suppose that we could standardize a way to expose |
40 |
> these. |
41 |
> |
42 |
|
43 |
+1, there is no strong tagging on every upstream. Maybe that's another |
44 |
topic but handling git sub modules et al could be made easier while |
45 |
satisfying our QA (or maybe make some exceptions) |
46 |
|
47 |
>> 3. Chicken and egg problem. If the library only has one consumer |
48 |
>> and you keep it bundled with that consumer forever, then it will |
49 |
>> probably only ever have one consumer. If somebody wants to use it |
50 |
>> in an overlay or something he'd have to pull in the whole |
51 |
>> program. |
52 |
> |
53 |
> If a Go developer wants to use the libraries in question, then |
54 |
> he'll probably use 'go get' to install them. I doubt the existence |
55 |
> of an ebuild will have much relevance in people's decision to adopt |
56 |
> a given Go library. |
57 |
> |
58 |
>> 4. Ebuild complexity. Now you have to compile e.g. three packages |
59 |
>> in src_compile, install three packages in src_install, etc. The |
60 |
>> result is more complicated than building once, three times. |
61 |
> |
62 |
> In the case of the consul ebuild, all of the libraries are |
63 |
> automatically built when the ebuild calls the emake. Even without a |
64 |
> Makefile, Go makes it trivial to build the dependencies. |
65 |
> |
66 |
|
67 |
Non live GIT ebuilds already make ebuilds more complex, this should |
68 |
indeed be enough. |
69 |
|
70 |
>> 5. One maintainer has to commit to maintaining all of the |
71 |
>> dependencies in addition to the program that he cares about. |
72 |
> |
73 |
> I guess that's a reasonable argument, depending on how much |
74 |
> maintenance the dependencies require. |
75 |
> |
76 |
|
77 |
Since there is no real Go support as such, this would be a pain ... |
78 |
|
79 |
>> Someone actually has to do the work to split out the libraries, |
80 |
>> so it may not be a clear-cut win in some cases. But it's nicer to |
81 |
>> have them split out should that happen by magic. |
82 |
> |
83 |
> Considering that Go binaries are statically linked, you'll end up |
84 |
> with a bunch of Go libraries installed that you don't need during |
85 |
> run-time. |
86 |
> |
87 |
|
88 |
+1, this defeats Go's main advantage imho (not that I think it's |
89 |
smart, but it's the actual fact) |
90 |
|
91 |
Cheers |