dev-lang/go always downloads and uses go-linux-{arch}-bootstrap-1.8.tbz for building a new version of go even if the the already installed version can be used. Reproducible: Always Steps to Reproduce: 1. emerge --depclean go # ensure go is not installed 2. emerge go 3. rm /usr/portage/distfiles/go-linux-*-bootstrap-1.8.tbz 4. emerge go Actual Results: emerge go in step 4 downloads go-linux-{arch}-bootstrap-1.8.tbz and uses it for building go Expected Results: installed go should be used for building new go It may seems minor, but it is important if user patches are applied. AFAIK dev-java/openjdk and dev-java/icedtea require an older version or -bin version to be installed for bootstrapping, shouldn't a similar dependency be applied to dev-lang/go
Created attachment 569738 [details] Ebuild proposal add system-bootstrap USE flag, that uses /usr/lib/go for bootstrapping. This implies a circular dependency if the USE flag is enabled when dev-lang/go is not already installed. If the circular dependency is a problem, dev-lang/go-bin should be created and used a dependency: || ( >=dev-lang/go-1.8.0 >=dev-lang/go-bin-1.8.0 ) Having a go-bin ebuild would also make the system-bootstrap USE flag useless
Created attachment 569740 [details] go-1.12.1.ebuild
This would also fix issue about building dev-lang/go on musl: * Bug 576290 - dev-lang/go no longer builds on musl (no bootstrap tarball is available, and sys-devel/gcc[go] does not build) * Bug 606970 - dev-lang/go-1.7.4 fails to compile on amd64-musl-hardened (./make.bash: line 132: /var/tmp/portage/dev-lang/go-1.7.4/work/go-linux-amd64-bootstrap/bin/go: No such file or directory)
Comment on attachment 569740 [details] go-1.12.1.ebuild --- go-1.12.1.ebuild 2019-03-17 22:34:25.907048328 +0100 +++ - 2019-03-18 23:30:05.817661561 +0100 @@ -47,16 +47,16 @@ ;; esac esac -SRC_URI+="!gccgo? ( ${BOOTSTRAP_URI} )" +SRC_URI+="!gccgo? ( !system-bootstrap? ( ${BOOTSTRAP_URI} ) )" DESCRIPTION="A concurrent garbage collected and typesafe programming language" HOMEPAGE="https://golang.org" LICENSE="BSD" SLOT="0/${PV}" -IUSE="gccgo" +IUSE="gccgo system-bootstrap" -BDEPEND="gccgo? ( >=sys-devel/gcc-5[go] )" +BDEPEND="gccgo? ( >=sys-devel/gcc-5[go] ) system-bootstrap? ( >=dev-lang/go-1.8.0 )" RDEPEND="!<dev-go/go-tools-0_pre20150902" # These test data objects have writable/executable stacks. @@ -156,7 +156,11 @@ src_compile() { - export GOROOT_BOOTSTRAP="${WORKDIR}"/go-$(go_os ${CBUILD})-$(go_arch ${CBUILD})-bootstrap + if use system-bootstrap; then + export GOROOT_BOOTSTRAP="/usr/lib/go" + else + export GOROOT_BOOTSTRAP="${WORKDIR}"/go-$(go_os ${CBUILD})-$(go_arch ${CBUILD})-bootstrap + fi if use gccgo; then mkdir -p "${GOROOT_BOOTSTRAP}/bin" || die local go_binary=$(gcc-config --get-bin-path)/go-$(gcc-major-version)
(In reply to Michel Ganguin from comment #0) > dev-lang/go always downloads and uses go-linux-{arch}-bootstrap-1.8.tbz for > building a new version of go even if the the already installed version can > be used. I don't see how the installed version could be used without breaking builds under crossdev (see bug #671394) The short version is the bootstrap binaries have to be run on the machine doing the building which may be different from where go is actually installed. If I offer a go-bin ebuild, it will download from upstream (https://golang.org/dl), and the go and go-bin ebuilds would block each other. Also, upstream does not support all of our architectures.
I do not really like the idea with system-bootstrap, as it will fail in case if golang was not yet present on the system. It would also means we do have non deterministic build process during update and the re-installation of package, as first it would use old version of golang to bootstrap, and on re-installation it would use the new version, meaning in theory running while update is in the tree: emerge -1u dev-lang/go emerge -1 dev-lang/go while USE=system-go is set would produce different results. May I ask what problem are you trying to solve here?
I am marking this invalid because I don't see a way I can avoid the downloads. Please feel free to re-open if you can come up with something that will still work in a crossdev environment.
