[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
From:       Zac Medico <zmedico () gentoo ! org>
Date:       2015-06-30 23:48:29
Message-ID: 55932ACD.9090703 () gentoo ! org
[Download RAW message or body]

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 undesirable
>> consequences, mainly that it means we'll be installing static libraries
>> that were only intended to be temporary build artifacts. It makes sense
>> to install them if there are multiple consumers, otherwise it doesn't
>> make much sense.
>  
>  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 from the dependencies.
> 
>  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?

If we did this with consul, for example, then the source code for all
those libraries (that have no other consumers) would have to be
installed in order to build consul-template against the consul's api
library. It would be similar to a header dependency. This would
necessitate the introduction of "build-against" dependencies [1], or
equivalent virtuals (like virtual/podofo-build).

> The only down side of this would be that there might be longer rebuilds
> if the packages have multiple consumers, but it gets rid of the static
> objects.
> 
> What do you think?

Considering the similarity to header dependencies, I don't know. The
subslot thing seems slightly more appealing to me.

[1] https://bugs.gentoo.org/show_bug.cgi?id=392239
-- 
Thanks,
Zac

[prev in list] [next in list] [prev in thread] [next in thread]