| 1 |
On Tue, Jun 30, 2015 at 04:48:29PM -0700, Zac Medico wrote: |
| 2 |
> On 06/30/2015 03:08 PM, William Hubbs wrote: |
| 3 |
> > Thinking about this, there may be a third option. This would take a |
| 4 |
> > slight reworking of the golang-build.eclass, but that is easy to do, |
| 5 |
> > and it would possibly remove the subslot from the dependencies. |
| 6 |
> > |
| 7 |
> > The source code is where the compatibility between versions of Go is, |
| 8 |
> > not the static objects, so what if, for third-party go packages, we |
| 9 |
> > skip installing the static objects? |
| 10 |
> |
| 11 |
> If we did this with consul, for example, then the source code for all |
| 12 |
> those libraries (that have no other consumers) would have to be |
| 13 |
> installed in order to build consul-template against the consul's api |
| 14 |
> library. It would be similar to a header dependency. This would |
| 15 |
> necessitate the introduction of "build-against" dependencies [1], or |
| 16 |
> equivalent virtuals (like virtual/podofo-build). |
| 17 |
|
| 18 |
How is this different from DEPEND="dev-go/podofo" for example or |
| 19 |
DEPEND=">=dev-go/fodofo-0_prexxxxxxxx"? |
| 20 |
|
| 21 |
> > The only down side of this would be that there might be longer rebuilds |
| 22 |
> > if the packages have multiple consumers, but it gets rid of the static |
| 23 |
> > objects. |
| 24 |
> > |
| 25 |
> > What do you think? |
| 26 |
> |
| 27 |
> Considering the similarity to header dependencies, I don't know. The |
| 28 |
> subslot thing seems slightly more appealing to me. |
| 29 |
|
| 30 |
I got the idea of not installing the objects from Debian's description |
| 31 |
of how they do this [1]; they do not mention installing the objects. |
| 32 |
|
| 33 |
Let me know what you think. |
| 34 |
|
| 35 |
William |
| 36 |
|
| 37 |
[1] http://pkg-go.alioth.debian.org/packaging.html |
Archives