From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4D01F138E20 for ; Wed, 19 Feb 2014 11:36:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75512E0C3D; Wed, 19 Feb 2014 11:36:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0FEAEE0C20 for ; Wed, 19 Feb 2014 11:36:41 +0000 (UTC) Received: from localhost (ip-213-220-199-65.net.upcbroadband.cz [213.220.199.65]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: yac) by smtp.gentoo.org (Postfix) with ESMTPSA id 5A6F933F8A8 for ; Wed, 19 Feb 2014 11:36:40 +0000 (UTC) Date: Wed, 19 Feb 2014 12:34:22 +0100 From: yac To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] dev-lang/go Message-ID: <20140219123422.702e5210@gentoo.org> In-Reply-To: <20140215224409.GA1593@laptop.home> References: <20131230154817.34a69433@ciguri> <20140211013844.4057ddb2@gentoo.org> <20140213175916.GA1919@laptop.home> <20140214133010.153a46b8@deathstar> <20140214110249.27842f70@ciguri> <20140215004844.49e9b7f2@gentoo.org> <20140215224409.GA1593@laptop.home> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/QyU7KWknPZ+8T=ZX3_kQYV7"; protocol="application/pgp-signature" X-Archives-Salt: dcdd76ba-2b1f-41a2-9a92-681681eed48a X-Archives-Hash: e0c4ac845b4690963bdaeba22ddb2e8d --Sig_/QyU7KWknPZ+8T=ZX3_kQYV7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 15 Feb 2014 16:44:09 -0600 William Hubbs wrote: > On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote: > > On Fri, 14 Feb 2014 11:02:49 -0500 > > Emery Hemingway wrote: > > > The default GOROOT that go looks at for base libraries seems to be > > > compiled in so this should be pretty easy, like python but > > > simplier. > >=20 > > I'm not sure what you are trying to solve here. Afaik GOROOT is > > used to determine where to install and it can be overriden from env. >=20 > Not overridden, but extended. See go help gopath. >=20 > > > An eclass could look at a GO_MINIMUM variable and install for each > > > version go that is present and matches. > >=20 > > It might be good idea to learn from others who'd been through this > > and I think the new python eclasses are good ones, going with > > something like PYTHON_TARGETS array (GOLANG_TARGETS ?) > =20 > I would prefer go_targets if this becomes an issue, golang is more search friendly > but it isn't at > this point because there is only one target, go1, and we do not know > if there will be a go2 or not. There still are different compilers at least, even if changing minor version would be a non-issue. But I'm not familiar with those, I think those are used for compiling for other than the supported archs (iirc only x86 and x86_64) > > > Dropping old versions of go > > > will be easy because linking wont break, and new releases should > > > be forwards compatible. > >=20 > > So far yes I think but I guess that may be quite different with in > > the future with >1.x, and "should be" so there may be corner cases > > where the user does need to use earlier version. >=20 > Highly unlikely in the context of go1, and again, we don't know if > there is going to even be a go2 or not. The only reason there will be > a go2 is if there needs to be a change at the source level which can > only be done in a backward incompatible way. >=20 > The question really should be, do we want a system-wide workspace to > store third-party libraries [1]? > and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist > along side /usr/lib/go? I assume you are talking about thirdparty packages installed by portage, not by localy/manually by user. Well, without the system-wide workspace to store the libraries, this whole go eclass would be kinda pointless, no? Currently /usr/lib/go/gentoo is used and I see no reason to change it. >=20 > The catch would be that every time you upgrade dev-lang/go, everything > stored in /usr/lib/go-gentoo has to be recompiled because there is no > guarantee that the libraries we have there are compatible with each > minor release of go1, only the source. >=20 > Then, the executables we have in /usr/bin will still run, but it would > be good to rebuild them as well to get the new libraries linked into > them. >=20 > If we had a work space in, say, /usr/lib/go-gentoo, we could leave the > executables in there and symlink them to /usr/bin. If we did that, it > would be easy for a user to rebuild everything in the workspace for > the new go by doing >=20 > emerge /usr/lib/go-gentoo/bin Good idea. > Thoughts? >=20 > William >=20 > [1] http://golang.org/doc/code.html --- Jan Mat=C4=9Bjka | Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B --Sig_/QyU7KWknPZ+8T=ZX3_kQYV7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJTBJbBAAoJEIN+7RD5ejahZV4H/A4wRVEQnCcx/iaPmxklDLn1 oiPvMff+lBSaHb8gwfpaDxtlZ4gi96wJ7DMCTp1njFukPytNdU0Php0CLKIEn1zg Kw7PnLJZcnOGQy6llS1Aeq71DC6pnf7j4z2DbcMGphjsxtheWBFtwPh7QMDjybAC YgwRgy+gttaQHbSnIZGugbkqvd3uRl7QKWLC43zIaIsrLpLvMozzMrgvNO2GGw0V sSPMMajjF0VxgVcgH8btxRLZI9mHwKh87fTIm2eykrxce+Kuq1f5dvWAWr5EK2AL FcQtwCrdAyPIgUO6K5cZtmcisKetPhRBYNNCAfkihvegiCnV2bgy3G045FqBqjI= =lg5R -----END PGP SIGNATURE----- --Sig_/QyU7KWknPZ+8T=ZX3_kQYV7--