On 07/04/2015 01:33 PM, Zac Medico wrote:
> On 07/04/2015 01:24 PM, William Hubbs wrote:
>> What am I missing?
>
> You need to recognize that "build-time for package A" is not the same as
> "build-time for package B". When you build go-tools, you can't rely on
> the build-time dependencies of go-n
On 07/04/2015 01:24 PM, William Hubbs wrote:
> On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote:
>> On 07/04/2015 12:32 PM, William Hubbs wrote:
>>> On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
On 06/30/2015 03:08 PM, William Hubbs wrote:
> The source code is wher
On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote:
> On 07/04/2015 12:32 PM, William Hubbs wrote:
> > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
> >> On 06/30/2015 03:08 PM, William Hubbs wrote:
> >>> The source code is where the compatibility between versions of Go is,
>
On 07/04/2015 12:32 PM, William Hubbs wrote:
> On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
>> On 06/30/2015 03:08 PM, William Hubbs wrote:
>>> The source code is where the compatibility between versions of Go is,
>>> not the static objects, so what if, for third-party go packages,
On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
> On 06/30/2015 03:08 PM, William Hubbs wrote:
> > The source code is where the compatibility between versions of Go is,
> > not the static objects, so what if, for third-party go packages, we
> > skip installing the static objects?
> >
On 06/30/2015 03:08 PM, William Hubbs wrote:
> The source code is where the compatibility between versions of Go is,
> not the static objects, so what if, for third-party go packages, we
> skip installing the static objects?
>
> The only down side of this would be that there might be longer rebu
On 06/30/2015 07:01 PM, William Hubbs wrote:
> On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote:
>> On 06/30/2015 03:08 PM, William Hubbs wrote:
>>> Thinking about this, there may be a third option. This would take a
>>> slight reworking of the golang-build.eclass, but that is easy to d
On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote:
> On 06/30/2015 03:08 PM, William Hubbs wrote:
> > Thinking about this, there may be a third option. This would take a
> > slight reworking of the golang-build.eclass, but that is easy to do,
> > and it would possibly remove the subslot
On 06/30/2015 03:08 PM, William Hubbs wrote:
> On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote:
>> On 06/30/2015 01:30 PM, William Hubbs wrote:
>>>
>>> I don't really see what the competing concerns are in this case.
>>
>> The competing concern is that un-bundling has some possibly un
On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote:
> On 06/30/2015 01:30 PM, William Hubbs wrote:
> > On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote:
> >> On 06/30/2015 08:35 AM, William Hubbs wrote:
> >>> All,
> >>>
> >>> we have digressed a bit, so I want to bring the discuss
On 06/30/2015 01:30 PM, William Hubbs wrote:
> On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote:
>> On 06/30/2015 08:35 AM, William Hubbs wrote:
>>> All,
>>>
>>> we have digressed a bit, so I want to bring the discussion back to what
>>> my main concerns are about this issue.
>>>
>>> 1. S
On Tue, Jun 30, 2015 at 10:53:58AM -0700, Zac Medico wrote:
> On 06/30/2015 08:35 AM, William Hubbs wrote:
> > All,
> >
> > we have digressed a bit, so I want to bring the discussion back to what
> > my main concerns are about this issue.
> >
> > 1. Should we bundle Go packages with Go software?
On 06/30/2015 11:25 AM, Michael Orlitzky wrote:
> On 06/30/2015 02:12 PM, Zac Medico wrote:
>>
>>> Suppose ten years from now everything is written in Go. I have 500
>>> statically linked Go packages on my system, all of whose dependencies
>>> were built and compiled-in at install time. Now someone
On 06/30/2015 02:12 PM, Zac Medico wrote:
>
>> Suppose ten years from now everything is written in Go. I have 500
>> statically linked Go packages on my system, all of whose dependencies
>> were built and compiled-in at install time. Now someone finds a remote
>> root vulnerability in the go-opens
On 06/30/2015 11:12 AM, Zac Medico wrote:
> As I mentioned in my reply to William [1], we might invent a notion of
> having one ebuild execute another ebuild in order to install static
> dependencies into a temporary build directory. That way, static
> libraries would be built on-demand, and disca
On 06/30/2015 08:49 AM, Michael Orlitzky wrote:
> On 06/29/2015 11:25 PM, Zac Medico wrote:
>>
>> Considering that Go binaries are statically linked, you'll end up with a
>> bunch of Go libraries installed that you don't need during run-time.
>>
>
> They'll eventually give this up, because everyon
On 06/30/2015 08:35 AM, William Hubbs wrote:
> All,
>
> we have digressed a bit, so I want to bring the discussion back to what
> my main concerns are about this issue.
>
> 1. Should we bundle Go packages with Go software?
>
> If we do, except for the Go standard library which is part of
> dev-l
On 06/29/2015 11:25 PM, Zac Medico wrote:
>
> Considering that Go binaries are statically linked, you'll end up with a
> bunch of Go libraries installed that you don't need during run-time.
>
They'll eventually give this up, because everyone does when their
language starts seeing serious use. I
All,
we have digressed a bit, so I want to bring the discussion back to what
my main concerns are about this issue.
1. Should we bundle Go packages with Go software?
If we do, except for the Go standard library which is part of
dev-lang/go, do we need to bother with installing Go sources and
pac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/06/2015 05:25, Zac Medico wrote:
> On 06/29/2015 07:24 PM, Michael Orlitzky wrote:
>> On 06/29/2015 07:44 PM, Zac Medico wrote:
>>>
Having faced the exact same problem I have to say I agree 100% with
Zac. I'd like to say that Gentoo needs thi
On 06/29/2015 07:24 PM, Michael Orlitzky wrote:
> On 06/29/2015 07:44 PM, Zac Medico wrote:
>>
>> While it would certainly be possible to split out a number of separate
>> ebuilds for Go libraries that are used *exclusively* by consul, what
>> advantages would it have?
>
> Even in this limiting ca
On 06/29/2015 07:08 PM, wirel...@tampabay.rr.com wrote:
> On 06/29/2015 06:50 PM, Zac Medico wrote:
>> On 06/29/2015 05:27 PM, wirel...@tampabay.rr.com wrote:
>>> On 06/29/2015 05:50 PM, Zac Medico wrote:
On 06/29/2015 02:27 PM, William Hubbs wrote:
> All,
>
> we have several Go eb
On 06/29/2015 07:44 PM, Zac Medico wrote:
>
> While it would certainly be possible to split out a number of separate
> ebuilds for Go libraries that are used *exclusively* by consul, what
> advantages would it have?
Even in this limiting case,
1. You avoid pointless rebuilds. You rebuild the l
On 06/29/2015 06:50 PM, Zac Medico wrote:
On 06/29/2015 05:27 PM, wirel...@tampabay.rr.com wrote:
On 06/29/2015 05:50 PM, Zac Medico wrote:
On 06/29/2015 02:27 PM, William Hubbs wrote:
All,
we have several Go ebuilds in the tree that bundle multiple separate
upstream sources. One example is a
On 06/29/2015 05:27 PM, wirel...@tampabay.rr.com wrote:
> On 06/29/2015 05:50 PM, Zac Medico wrote:
>> On 06/29/2015 02:27 PM, William Hubbs wrote:
>>> All,
>>>
>>> we have several Go ebuilds in the tree that bundle multiple separate
>>> upstream sources. One example is app-admin/consul-0.5.2.
>>>
On 06/29/2015 05:50 PM, Zac Medico wrote:
On 06/29/2015 02:27 PM, William Hubbs wrote:
All,
we have several Go ebuilds in the tree that bundle multiple separate
upstream sources. One example is app-admin/consul-0.5.2.
My thought is that we shouldn't bundle like this, but we should figure
out h
On 06/29/2015 02:27 PM, William Hubbs wrote:
> All,
>
> we have several Go ebuilds in the tree that bundle multiple separate
> upstream sources. One example is app-admin/consul-0.5.2.
>
> My thought is that we shouldn't bundle like this, but we should figure
> out how to write ebuilds for the dep
All,
we have several Go ebuilds in the tree that bundle multiple separate
upstream sources. One example is app-admin/consul-0.5.2.
My thought is that we shouldn't bundle like this, but we should figure
out how to write ebuilds for the dependent packages as well.
What do others think?
William
28 matches
Mail list logo
