On 06/30/2015 07:01 PM, William Hubbs wrote: > 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 virtual/podofo-build package pulls in dev-libs/boost, since packages which build against podofo will fail to build unless the boost headers are installed. Since dev-libs/boost is not a run-time dependency of podofo, and it's not a direct build-time dependency of packages that build against podofo, we pull it in via virtual/podofo-build. If we install Go source files without the corresponding static libraries, they we create a similar situation to the above. For example, if consul doesn't install its static api library, then anything that wants to build against that library is going to need indirect dependencies installed in order to build that library. The indirect dependencies are not needed if there is an installed instance of consul's static api library. >>> 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 > As I understand it, debian does the equivalent of putting the Go dependencies in both DEPEND and RDEPEND. This means that users are forced to keep build-time dependencies around after they are no longer needed. -- Thanks, Zac
