| 1 |
On 06/29/2015 07:44 PM, Zac Medico wrote: |
| 2 |
> |
| 3 |
> While it would certainly be possible to split out a number of separate |
| 4 |
> ebuilds for Go libraries that are used *exclusively* by consul, what |
| 5 |
> advantages would it have? |
| 6 |
|
| 7 |
Even in this limiting case, |
| 8 |
|
| 9 |
1. You avoid pointless rebuilds. You rebuild the library (and |
| 10 |
probably the binary, for Go packages) when the library is upgraded |
| 11 |
rather than rebuilding everything whenever anything is updated. |
| 12 |
|
| 13 |
2. Security. If upstream treats the packages as separate, a user |
| 14 |
might hear that there's a security issue in libfoo but then run |
| 15 |
eix and see that he doesn't have libfoo installed (because it's |
| 16 |
bundled). |
| 17 |
|
| 18 |
3. Chicken and egg problem. If the library only has one consumer and |
| 19 |
you keep it bundled with that consumer forever, then it will |
| 20 |
probably only ever have one consumer. If somebody wants to use |
| 21 |
it in an overlay or something he'd have to pull in the whole |
| 22 |
program. |
| 23 |
|
| 24 |
4. Ebuild complexity. Now you have to compile e.g. three packages in |
| 25 |
src_compile, install three packages in src_install, etc. The result |
| 26 |
is more complicated than building once, three times. |
| 27 |
|
| 28 |
5. One maintainer has to commit to maintaining all of the dependencies |
| 29 |
in addition to the program that he cares about. |
| 30 |
|
| 31 |
Someone actually has to do the work to split out the libraries, so it |
| 32 |
may not be a clear-cut win in some cases. But it's nicer to have them |
| 33 |
split out should that happen by magic. |
Archives