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 E0BB0138334 for ; Thu, 12 Sep 2019 17:03:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9EE8EE09E1; Thu, 12 Sep 2019 17:03:08 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 34D18E09CE for ; Thu, 12 Sep 2019 17:03:08 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 512BA34B0C5; Thu, 12 Sep 2019 17:03:06 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 12 Sep 2019 19:03:02 +0200 In-Reply-To: <20190912163954.GA24121@whubbs1.dev.av1.gaikai.org> References: <20190911172128.18885-1-williamh@gentoo.org> <20190911172128.18885-2-williamh@gentoo.org> <1839d49b6adcfeba3c807543e0ba01e0f2888a36.camel@gentoo.org> <20190911182238.GA19361@whubbs1.dev.av1.gaikai.org> <20190911194041.GA19620@whubbs1.dev.av1.gaikai.org> <20190911231115.GA20687@whubbs1.dev.av1.gaikai.org> <06381929-4520-4284-B868-EB83D5AE3D6B@gentoo.org> <20190912163954.GA24121@whubbs1.dev.av1.gaikai.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-4D0UU0Pko6S8q+CLfcSy" User-Agent: Evolution 3.32.4 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 X-Archives-Salt: 2481d645-d097-4517-96c5-7400777727b1 X-Archives-Hash: 4321be5e73635404ca4a0b3328de91c7 --=-4D0UU0Pko6S8q+CLfcSy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2019-09-12 at 11:39 -0500, William Hubbs wrote: > On Thu, Sep 12, 2019 at 05:39:42AM +0000, Micha=C5=82 G=C3=B3rny wrote: > > Dnia September 11, 2019 11:11:15 PM UTC, William Hubbs napisa=C5=82(a): > > > You are right, and currently I quietly ignore your vendor tarball if > > > upstream > > > vendors the dependencies also. I could change this to generate a > > > warning > > > or die and force you to fix the ebuild, but that would not be possibl= e > > > if I follow your suggestion because I would not be able to tell wheth= er > > > the vendored dependencies came from us or upstream. > >=20 > > Why would anyone create a vendor tarball if things work without it? Tha= t makes no sense. Also adding unused archives to SRC_URI is a QA violation. >=20 > All the more reason to not have the vendor tarball overwrite the vendor > directory upstream. I will show you when I update the eclass. If there is a vendor directory, then you should not have custom vendor tarball to override it in the first place. If you have the tarball, the eclass should explode and tell the developer he's doing silly things and needs to stop, not silently pretend everything is fine and surprise people by coincidentally choosing not to do anything. >=20 > > > Also, another concern about your suggestion is the --transform switc= h > > > that would have to be added to the tar command people use to create > > > the > > > vendor tarball, something like: > > >=20 > > > tar -acvf package-version-vendor.tar.gz > > > --transform=3D's#^vendor#package-version-vendor#' vendor > > >=20 > > > You suggested that a maintainer could create a new tarball and build = on > > > top of it. I guess you mean don't use upstream's tarball if they don= 't > > > vendor and create my own tarball and add the vendor directory to it. > > > I'm > > > against that option because I don't feel that we should manually > > > tinker > > > with upstream tarballs. That opens a pretty big can of worms imo. > >=20 > > No. I suggested that rather than adding another git clone and checking = out a tag (which sooner or later would mean someone forgetting and using ma= ster instead), you could unpack the same archive you're going to use in the= ebuild. >=20 > Ok, I am really not following you, so let's talk about this in the > context of an example. >=20 > Look at app-misc/spire and tell me how you would do it differently. >=20 ebuild spire-0.8.1.ebuild fetch tar -xf ${DISTDIR}/spire-0.8.1.tar.gz cd spire-0.8.1/ go mod vendor cd ../ tar -cf spire-0.8.1-vendor.tar spire-0.8.1/vendor Now you don't need special src_prepare() to unpack it. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-4D0UU0Pko6S8q+CLfcSy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl16ekZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA4/vggAiIrwdafQP0b+y/nHiVMQ2oXPXFFGx+qD+0olZ/kGO6p4FvDlhUAsr41Y ioTYBRwyPPIk1cZzMf2ICVbLwF6qQLjpwg7q40h47bduRmHcWp6JyaSXDl6mwgS9 CPNZFhBCL/n4gTuoq0DVmpAMTum2uAsNJPWDk/ZE2KMnlmNa+iT5xx86TTSonjEb LcahVmDkGZ8JtkVXhRNV3q97g3+3oRn2/WjisYFKVzdz7xTQ55CjSfOwZG/AprWy CjAbogKrE5GzKMPzQMHG23BuwqBWrxsfMhSkkFrUWGYgXMMZsGrDzOcz1FOqshD4 P6dXaGYFM3PwUqSIEzfN82u0nA4fVA== =cdWB -----END PGP SIGNATURE----- --=-4D0UU0Pko6S8q+CLfcSy--