From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id CD472138334 for ; Mon, 16 Sep 2019 22:00:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF984E0A85; Mon, 16 Sep 2019 22:00:54 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 824A7E0A6A for ; Mon, 16 Sep 2019 22:00:54 +0000 (UTC) Received: from whubbs1.gaikai.biz (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id 4070E34B272; Mon, 16 Sep 2019 22:00:53 +0000 (UTC) Received: (nullmailer pid 28788 invoked by uid 1000); Mon, 16 Sep 2019 22:00:48 -0000 Date: Mon, 16 Sep 2019 17:00:48 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: zmedico@gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules Message-ID: <20190916220048.GA28491@whubbs1.dev.av1.gaikai.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org, zmedico@gentoo.org References: <20190916141719.12922-1-williamh@gentoo.org> <20190916141719.12922-2-williamh@gentoo.org> <2f70ef66-63d7-0359-17a0-e517979f700d@gentoo.org> <20190916183500.GB27855@whubbs1.dev.av1.gaikai.org> 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 7a75a0cb-56fa-451b-995e-e2a850e9adbe X-Archives-Hash: f162dd3c31870cb326641e53f3d95777 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > On 9/16/19 11:35 AM, William Hubbs wrote: > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > >> For packages that I maintain, I'd prefer to continue using EGO_VENDOR = to > >> even with packages using go.mod. I hope that this go-module.class will > >> not preclude this sort of usage. For example, the latest go-tools ebui= ld > >> uses EGO_VENDOR together with GOFLAGS=3D"-mod=3Dvendor": > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3D8cc6d401139526e= 2f9a6dbadbd31f0ff2387705f > >=20 > > Can you elaborate on why you want to keep EGO_VENDOR? > >=20 > > The "go mod vendor" command above downloads all the correct versions > > of the dependencies and puts them in the vendor directory, so I'm not > > sure why you would need the EGO_VENDOR variable. >=20 > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > containing vendored dependencies. It's more space-efficient in the sense > that each vendored dependency is stored in a separate tarball, so > multiple ebuilds can share the same tarball if the version of a > particular vendored dependency has not changed. I see what you are saying, but I haven't yet found a way to generate these separate tarballs that I'm comfortable with. Also, thinking about this, there will be many more tarballs on our mirrors if we store one dependency in each tarball than if we generate vendor tarballs that contain all dependencies for a package. I would consider this an enhancement to the eclass if you still feel that we need it, but let me get the eclass into the tree first then we can work on that. Thanks, William --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCXYAGBQAKCRBuVBb0MMRl ODwOAJ0daK7VxZ0KGAuAAl4BlXLvmmaZ/wCeNh6Wg6XVJQTi3hqe+wZK61noOfM= =AUx8 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--