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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BADBA15806E for ; Thu, 1 Jun 2023 19:55:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D418BE0819; Thu, 1 Jun 2023 19:55:03 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 90CE1E07D0 for ; Thu, 1 Jun 2023 19:55:03 +0000 (UTC) Received: (nullmailer pid 2774 invoked by uid 1000); Thu, 01 Jun 2023 19:55:00 -0000 Date: Thu, 1 Jun 2023 14:55:00 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EGO_SUM Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <49ce8700-6c96-9360-51cf-2a989f666752@gentoo.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="CXNzusiWuOjedayH" Content-Disposition: inline In-Reply-To: <49ce8700-6c96-9360-51cf-2a989f666752@gentoo.org> X-Archives-Salt: db0eebe7-0419-445b-beb6-c9e78ab03561 X-Archives-Hash: f00fbcb82f49cd0ffd4dde7a168db042 --CXNzusiWuOjedayH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I know I'm pretty late to this thread, but I'm going to respond to some of the concerns and suggest another alternative. On Mon, Apr 17, 2023 at 09:37:32AM +0200, Florian Schmaus wrote: > I want to continue the discussion to re-instate EGO_SUM, potentially=20 > leading to a democratic vote on whether EGO_SUM should be re-instated or= =20 > deprecated. >=20 > For the past months, I tried to find *technical reasons*, e.g., reasons= =20 > that affect end-users, that justify the deprecation of EGO_SUM. However,= =20 > I was unable to find any. The closest thing I could find was portage=20 > being unable to process an ebuild due to its large environment (bug=20 > 830187). However, as this happens while developing an ebuild, it should= =20 > never affect users. Obviously this is a situation where EGO_SUM can not= =20 > be used. Fortunately, it does not affect most Go packages, as seen in my= =20 > previous analysis of Go packages in ::gentoo and their EGO_SUM size.=20 > Furthermore, newer portage versions, with USE=3Dgentoo-dev, will=20 > proactively warn you if the environment caused by the ebuild becomes larg= e. >=20 > All further arguments for the deprecation of EGO_SUM where of cosmetic=20 > nature. >=20 > However, the deprecation of EGO_SUM is harmful to Gentoo and its users.= =20 > To briefly re-iterate the reasons: >=20 > The EGO_SUM alternatives > - do not have the same level of trust and therefore have a negative=20 > impact on security (a dubious tarball someone put somewhere, especially= =20 > when proxy-maint) For this, I would argue that vetting the tarball falls to the developer who is proxying. If you don't trust the proxy maintainer you are pushing for, it is easy to make a dependency tarball yourself and add it to your dev space. > - are not easily verifiable I don't have a response to this other than to say that go does its own verification of modules with the dependency tarballs that it can't do with vendor tarballs. > - require additional effort when developing ebuilds This "additional effort" is pretty subjective. Making a dependency tarball isn't a lot of work, especially with the script that I posted in this threa= d. > - hinder the packaging and Gentoo's adoption of Go-based projects, which= =20 > is worrisome as Go is very popular I don't have a response here. I don't see it as much of a henderance (this is obviously subjective). > - prevent Go modules from being shared as DISTFILES on the mirrors=20 > across various packages =20 The issue here is really the duplicate data in the dependency or vendor tarballs, and yes, there is a lot of it. > Last but not least, we have the same situation in the Rust ecosystem,=20 > but we allow the EGO_SUM "equivalent" there. I'm not sure it is quite the same because Rust projects tend to have much smaller numbers of dependencies. Another thing to consider is that using EGO_SUM adds a significant amount of processing to the go-module eclass. I was advised recently that this isn't a good idea since bash is slow, so I am considering moving most of that processing into get-ego-vendor by having it generate the contents of SRC_URI directly instead of using the eclass code to do that. My thought is to have get-ego-vendor output the value for a variable, GO_SRC_URI and add that to SRC_URI in the ebuild like so: # The output from get-ego-vendor: GO_SRC_URI=3D" # dependency 1 # dependency 2 " SRC_URI=3D"https://main-project-here ${GO_SRC_URI}" This should speed things up some since most of the processing we are doing in the eclass would be removed, so I would rather not see the council force the use of EGO_SUM. This, however, is still going to hit the limitation of bug 830187. I am, however, open to another solution, so I will keep following this thread. I think the better question should be around what we can do to get bug 7210= 88 or bug 833567 to move forward. Thanks, William --CXNzusiWuOjedayH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCZHj3jQAKCRBuVBb0MMRl ONSpAJ42dr9iXaW3reiFJBjki0tjl5VETACcCwcRhzVTpNUrXTZOVtxIF9w+MFc= =HuiG -----END PGP SIGNATURE----- --CXNzusiWuOjedayH--