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 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).
How is this different from DEPEND="dev-go/podofo" for example or DEPEND=">=dev-go/fodofo-0_prexxxxxxxx"? > > 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. I got the idea of not installing the objects from Debian's description of how they do this [1]; they do not mention installing the objects. Let me know what you think. William [1] http://pkg-go.alioth.debian.org/packaging.html
signature.asc
Description: Digital signature
