| 1 |
On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote: |
| 2 |
> On 06/30/2015 01:30 PM, William Hubbs wrote: |
| 3 |
> > On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote: |
| 4 |
> >> On 06/30/2015 08:35 AM, William Hubbs wrote: |
| 5 |
> >>> All, |
| 6 |
> >>> |
| 7 |
> >>> we have digressed a bit, so I want to bring the discussion back to what |
| 8 |
> >>> my main concerns are about this issue. |
| 9 |
> >>> |
| 10 |
> >>> 1. Should we bundle Go packages with Go software? |
| 11 |
> >>> |
| 12 |
> >>> If we do, except for the Go standard library which is part of |
| 13 |
> >>> dev-lang/go, do we need to bother with installing Go sources and |
| 14 |
> >>> packages at all? |
| 15 |
> >>> |
| 16 |
> >>> The down side of the whole bundling idea is that every consumer |
| 17 |
> >>> on someone's system could potentially have a different version of the |
| 18 |
> >>> Go package, which doesn't lend itself well to security concerns. |
| 19 |
> >>> |
| 20 |
> >>> This is why bundling is generally discouraged in Gentoo. |
| 21 |
> >> |
| 22 |
> >> Yes, as a general rule, bundling is sub-optimal. However, there are |
| 23 |
> >> often exceptions to general rules like these, especially when there are |
| 24 |
> >> competing concerns to contend with. |
| 25 |
> > |
| 26 |
> > I don't really see what the competing concerns are in this case. |
| 27 |
> |
| 28 |
> The competing concern is that un-bundling has some possibly undesirable |
| 29 |
> consequences, mainly that it means we'll be installing static libraries |
| 30 |
> that were only intended to be temporary build artifacts. It makes sense |
| 31 |
> to install them if there are multiple consumers, otherwise it doesn't |
| 32 |
> make much sense. |
| 33 |
|
| 34 |
Thinking about this, there may be a third option. This would take a |
| 35 |
slight reworking of the golang-build.eclass, but that is easy to do, |
| 36 |
and it would possibly remove the subslot from the dependencies. |
| 37 |
|
| 38 |
The source code is where the compatibility between versions of Go is, |
| 39 |
not the static objects, so what if, for third-party go packages, we |
| 40 |
skip installing the static objects? |
| 41 |
|
| 42 |
The only down side of this would be that there might be longer rebuilds |
| 43 |
if the packages have multiple consumers, but it gets rid of the static |
| 44 |
objects. |
| 45 |
|
| 46 |
What do you think? |
| 47 |
|
| 48 |
William |
Archives