| 1 |
On 06/30/2015 07:01 PM, William Hubbs wrote: |
| 2 |
> On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote: |
| 3 |
>> On 06/30/2015 03:08 PM, William Hubbs wrote: |
| 4 |
>>> Thinking about this, there may be a third option. This would take a |
| 5 |
>>> slight reworking of the golang-build.eclass, but that is easy to do, |
| 6 |
>>> and it would possibly remove the subslot from the dependencies. |
| 7 |
>>> |
| 8 |
>>> The source code is where the compatibility between versions of Go is, |
| 9 |
>>> not the static objects, so what if, for third-party go packages, we |
| 10 |
>>> skip installing the static objects? |
| 11 |
>> |
| 12 |
>> If we did this with consul, for example, then the source code for all |
| 13 |
>> those libraries (that have no other consumers) would have to be |
| 14 |
>> installed in order to build consul-template against the consul's api |
| 15 |
>> library. It would be similar to a header dependency. This would |
| 16 |
>> necessitate the introduction of "build-against" dependencies [1], or |
| 17 |
>> equivalent virtuals (like virtual/podofo-build). |
| 18 |
> |
| 19 |
> How is this different from DEPEND="dev-go/podofo" for example or |
| 20 |
> DEPEND=">=dev-go/fodofo-0_prexxxxxxxx"? |
| 21 |
|
| 22 |
The virtual/podofo-build package pulls in dev-libs/boost, since packages |
| 23 |
which build against podofo will fail to build unless the boost headers |
| 24 |
are installed. Since dev-libs/boost is not a run-time dependency of |
| 25 |
podofo, and it's not a direct build-time dependency of packages that |
| 26 |
build against podofo, we pull it in via virtual/podofo-build. |
| 27 |
|
| 28 |
If we install Go source files without the corresponding static |
| 29 |
libraries, they we create a similar situation to the above. For example, |
| 30 |
if consul doesn't install its static api library, then anything that |
| 31 |
wants to build against that library is going to need indirect |
| 32 |
dependencies installed in order to build that library. The indirect |
| 33 |
dependencies are not needed if there is an installed instance of |
| 34 |
consul's static api library. |
| 35 |
|
| 36 |
>>> The only down side of this would be that there might be longer rebuilds |
| 37 |
>>> if the packages have multiple consumers, but it gets rid of the static |
| 38 |
>>> objects. |
| 39 |
>>> |
| 40 |
>>> What do you think? |
| 41 |
>> |
| 42 |
>> Considering the similarity to header dependencies, I don't know. The |
| 43 |
>> subslot thing seems slightly more appealing to me. |
| 44 |
> |
| 45 |
> I got the idea of not installing the objects from Debian's description |
| 46 |
> of how they do this [1]; they do not mention installing the objects. |
| 47 |
> |
| 48 |
> Let me know what you think. |
| 49 |
> |
| 50 |
> William |
| 51 |
> |
| 52 |
> [1] http://pkg-go.alioth.debian.org/packaging.html |
| 53 |
> |
| 54 |
|
| 55 |
As I understand it, debian does the equivalent of putting the Go |
| 56 |
dependencies in both DEPEND and RDEPEND. This means that users are |
| 57 |
forced to keep build-time dependencies around after they are no longer |
| 58 |
needed. |
| 59 |
-- |
| 60 |
Thanks, |
| 61 |
Zac |
Archives