dev-lang/go should really be slotted: 1) regressions happen fairly often for it so being able to test older versions is useful; 2) the eclass machinery for it would facilitate better integration of sys-devel/gcc[go] (gccgo); 3) it should be pretty easy given Go is never an RDEPEND This would mean doing three things: 1) making dev-lang/go co-installable; 2) forking go-module.eclass into go-module-r1.eclass and allow specifying GO_MIN_VER and GO_MAX_VER in there and generating a dep string based on it, then also setting GO or something to choose which is used for the build 3) maybe an eselect-go to allow users to choose which go is used for their shell (not ebuilds) (I thought we'd had a bug for this already but I can't find it.)
(In reply to Sam James from comment #0) > dev-lang/go should really be slotted: > 1) regressions happen fairly often for it so being able to test older > versions is useful; I've thought about this, I"m not sure whether we can answer it with the toolchains feature [1] or not, but if so that might be worth looking at before we do any slotting. > 2) the eclass machinery for it would facilitate better integration of > sys-devel/gcc[go] (gccgo); We haven't done any work with gccgo, and I'm not sure whether or not we want to; it is always a version or so behind dev-lang/go. > 3) it should be pretty easy given Go is never an RDEPEND > > This would mean doing three things: > 1) making dev-lang/go co-installable; This would require "eselect go" to exist immediately because I would have to make "go" and "gofmt" eselectable. > 2) forking go-module.eclass into go-module-r1.eclass and allow specifying > GO_MIN_VER and GO_MAX_VER in there and generating a dep string based on it, > then also setting GO or something to choose which is used for the build Since We have only two versions of go in the tree (the current and previous releases) to conform to upstream's release policy, the go BDEPEND will be either "=dev-lang/go-version*" or "dev-lang/go". > 3) maybe an eselect-go to allow users to choose which go is used for their > shell (not ebuilds) Off the top of my head, I don't see the use case for building something with an older version of go in the shell once a newer version is stable.
(In reply to William Hubbs from comment #1) > (In reply to Sam James from comment #0) > > dev-lang/go should really be slotted: > > 1) regressions happen fairly often for it so being able to test older > > versions is useful; > > I've thought about this, I"m not sure whether we can answer it with the > toolchains feature [1] or not, but if so that might be worth looking at > before we do any slotting. > > > 2) the eclass machinery for it would facilitate better integration of > > sys-devel/gcc[go] (gccgo); > > We haven't done any work with gccgo, and I'm not sure whether or not we want > to; it is always a version or so behind dev-lang/go. > The point is that we'd kind of get it for free. But it would mean we get more arch support and we don't have to rely on binaries. > > 3) it should be pretty easy given Go is never an RDEPEND > > > > This would mean doing three things: > > 1) making dev-lang/go co-installable; > > This would require "eselect go" to exist immediately because I would have to > make "go" and "gofmt" eselectable. > Sur.e > > 2) forking go-module.eclass into go-module-r1.eclass and allow specifying > > GO_MIN_VER and GO_MAX_VER in there and generating a dep string based on it, > > then also setting GO or something to choose which is used for the build > > Since We have only two versions of go in the tree (the current and previous > releases) to conform to upstream's release policy, the go BDEPEND will be > either "=dev-lang/go-version*" or > "dev-lang/go". I don't know why we'd need to do that. Besides, if it's unbound (dev-lang/go:* for the default case where GO_MIN_VER and GO_MAX_VER is unset), the latest Go will be dragged in anyway. > > > 3) maybe an eselect-go to allow users to choose which go is used for their > > shell (not ebuilds) > > Off the top of my head, I don't see the use case for building something with > an older version of go in the shell once a newer version is stable. Testing one's own projects with an older or newer Go, or being able to use a newer/older version of Go when something on your system requires newer/older? We already had users hit that kind of problem. The same reason that Ruby or Python is slotted, really..
It also facilitates proper bootstrapping of Go from previous versions of Go, and also e.g. using gccgo (even if just for bootstrapping) without relying on a binary download.
