On Fri, Jun 05, 2015 at 09:34:42AM -0500, William Hubbs wrote: > On Fri, Jun 05, 2015 at 12:54:45AM -0400, Mike Frysinger wrote: > > On 04 Jun 2015 14:10, William Hubbs wrote: > > > # @MAINTAINER: > > > # William Hubbs <willi...@gentoo.org> > > > # @BLURB: Eclass for fetching and unpacking go repositories. > > > # @DESCRIPTION: > > > # This eclass is written to ease the maintenance of live ebuilds > > > # of software written in the Go programming language. > > > > this should note the ebuild is responsible for depending on the right vcs > > packages. e.g. if you use git, then you need to depend on git. > > Since "go get" fetches $EGO_PN and its dependencies, there is no way an > ebuild author could get this right without reading all of the import > statements in the source for their package and all of its dependencies. > I don't really want to ask ebuild authors to keep up with all of that. > > > although ... > > > > > # @ECLASS-VARIABLE: EGO_PN > > > # @REQUIRED > > > # @DESCRIPTION: > > > # This is the import path for the go package. Please emerge dev-lang/go > > > # and read "go help importpath" for syntax. > > > # > > > # Example: > > > # @CODE > > > # EGO_PN="github.com/user/project" > > > # @CODE > > > > can't we automate some of the common hosts ? if it says github, we know > > it's > > going to be using at least git. > > I'm seeing two options. I can either let users emerge the vcs's they > need if something breaks or pull in all vcs's go supports. > > Which way is best?
The more I think about this, I don't want to DEPEND on any vcs's and it is not reasonable to ask developers to do so in their go vcs ebuilds for the reason I stated above. Since these are live ebuilds, I think we can assume more about the users that use them and not require the vcs's as runtime dependencies. William
signature.asc
Description: Digital signature
