1 |
On 06/30/2015 03:08 PM, William Hubbs wrote: |
2 |
> On Tue, Jun 30, 2015 at 02:34:52PM -0700, Zac Medico wrote: |
3 |
>> On 06/30/2015 01:30 PM, William Hubbs wrote: |
4 |
>>> |
5 |
>>> I don't really see what the competing concerns are in this case. |
6 |
>> |
7 |
>> The competing concern is that un-bundling has some possibly undesirable |
8 |
>> consequences, mainly that it means we'll be installing static libraries |
9 |
>> that were only intended to be temporary build artifacts. It makes sense |
10 |
>> to install them if there are multiple consumers, otherwise it doesn't |
11 |
>> make much sense. |
12 |
> |
13 |
> Thinking about this, there may be a third option. This would take a |
14 |
> slight reworking of the golang-build.eclass, but that is easy to do, |
15 |
> and it would possibly remove the subslot from the dependencies. |
16 |
> |
17 |
> The source code is where the compatibility between versions of Go is, |
18 |
> not the static objects, so what if, for third-party go packages, we |
19 |
> skip installing the static objects? |
20 |
|
21 |
If we did this with consul, for example, then the source code for all |
22 |
those libraries (that have no other consumers) would have to be |
23 |
installed in order to build consul-template against the consul's api |
24 |
library. It would be similar to a header dependency. This would |
25 |
necessitate the introduction of "build-against" dependencies [1], or |
26 |
equivalent virtuals (like virtual/podofo-build). |
27 |
|
28 |
> The only down side of this would be that there might be longer rebuilds |
29 |
> if the packages have multiple consumers, but it gets rid of the static |
30 |
> objects. |
31 |
> |
32 |
> What do you think? |
33 |
|
34 |
Considering the similarity to header dependencies, I don't know. The |
35 |
subslot thing seems slightly more appealing to me. |
36 |
|
37 |
[1] https://bugs.gentoo.org/show_bug.cgi?id=392239 |
38 |
-- |
39 |
Thanks, |
40 |
Zac |