1 |
On 06/29/2015 07:24 PM, Michael Orlitzky wrote: |
2 |
> On 06/29/2015 07:44 PM, Zac Medico wrote: |
3 |
>> |
4 |
>> While it would certainly be possible to split out a number of separate |
5 |
>> ebuilds for Go libraries that are used *exclusively* by consul, what |
6 |
>> advantages would it have? |
7 |
> |
8 |
> Even in this limiting case, |
9 |
> |
10 |
> 1. You avoid pointless rebuilds. You rebuild the library (and |
11 |
> probably the binary, for Go packages) when the library is upgraded |
12 |
> rather than rebuilding everything whenever anything is updated. |
13 |
|
14 |
From my experience, Go packages don't take very long to build. |
15 |
|
16 |
> 2. Security. If upstream treats the packages as separate, a user |
17 |
> might hear that there's a security issue in libfoo but then run |
18 |
> eix and see that he doesn't have libfoo installed (because it's |
19 |
> bundled). |
20 |
|
21 |
That's a reasonable motivation. However, many of these libraries don't |
22 |
have any tags. So, you'll have to use the commit hashes if you want to |
23 |
test for vulnerabilities. In the case of the consul ebuild, the commit |
24 |
hashes of the libraries are available in the SRC_URI. I suppose that we |
25 |
could standardize a way to expose these. |
26 |
|
27 |
> 3. Chicken and egg problem. If the library only has one consumer and |
28 |
> you keep it bundled with that consumer forever, then it will |
29 |
> probably only ever have one consumer. If somebody wants to use |
30 |
> it in an overlay or something he'd have to pull in the whole |
31 |
> program. |
32 |
|
33 |
If a Go developer wants to use the libraries in question, then he'll |
34 |
probably use 'go get' to install them. I doubt the existence of an |
35 |
ebuild will have much relevance in people's decision to adopt a given Go |
36 |
library. |
37 |
|
38 |
> 4. Ebuild complexity. Now you have to compile e.g. three packages in |
39 |
> src_compile, install three packages in src_install, etc. The result |
40 |
> is more complicated than building once, three times. |
41 |
|
42 |
In the case of the consul ebuild, all of the libraries are automatically |
43 |
built when the ebuild calls the emake. Even without a Makefile, Go makes |
44 |
it trivial to build the dependencies. |
45 |
|
46 |
> 5. One maintainer has to commit to maintaining all of the dependencies |
47 |
> in addition to the program that he cares about. |
48 |
|
49 |
I guess that's a reasonable argument, depending on how much maintenance |
50 |
the dependencies require. |
51 |
|
52 |
> Someone actually has to do the work to split out the libraries, so it |
53 |
> may not be a clear-cut win in some cases. But it's nicer to have them |
54 |
> split out should that happen by magic. |
55 |
|
56 |
Considering that Go binaries are statically linked, you'll end up with a |
57 |
bunch of Go libraries installed that you don't need during run-time. |
58 |
-- |
59 |
Thanks, |
60 |
Zac |