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 63B4C158094 for ; Fri, 30 Sep 2022 15:48:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 64063E0B34; Fri, 30 Sep 2022 15:48:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1DEF3E0B23 for ; Fri, 30 Sep 2022 15:48:55 +0000 (UTC) Received: (nullmailer pid 17086 invoked by uid 1000); Fri, 30 Sep 2022 15:48:52 -0000 Date: Fri, 30 Sep 2022 10:48:52 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Proposal to undeprecate EGO_SUM Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20220613074411.341909-1-flow@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="z/ioP4Uxf3NSI9ZI" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 9efd1cbc-095d-4e75-9b67-b1dbccff82d4 X-Archives-Hash: 3eeb78e919cedbbcf3523027f8cf5656 --z/ioP4Uxf3NSI9ZI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2022 at 04:53:39PM +0200, Florian Schmaus wrote: > On 30/09/2022 02.36, William Hubbs wrote: > > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: > >>>>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: > >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > >>> maintains the package > >>> 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > >>> maintainer maintains the package > >> > >> These numbers seem quite large, compared to the mean number of 3.4 > >> distfiles for packages in the Gentoo repository. (The median and the > >> 99-percentile are 1 and 22, respectively.) >=20 > The numbers may appear large when compared to the whole tree, but I=20 > think a fair comparison would be within the related programming language= =20 > ecosystem, e.g., Golang or Rust. >=20 > For example, analyzing ::gentoo yields the following histogram for=20 > 2022-01-01: > https://dev.gentoo.org/~flow/ego_sum_entries_histogram-2020-01-01.png >=20 >=20 > > To stay with your example, restic has a 300k manifest, multiple 30k+ > > ebuilds and897 distfiles. > >=20 > > I'm thinking the limit would have to be much lower. Say, around 256 > > entries in EGO_SUM_SRC_URI. >=20 > A limit of 256 appears to be to low to be of any use. It is slightly=20 > above the 50th percentile, half of the packages could not use it. >=20 > We have to realize that programming language ecosystems that only build= =20 > static binaries tend to produce software projects that have a large=20 > number of dependencies. For example, app-misc/broot, a tool written in=20 > Rust, has currently 310 entries in its Manifest. Why should we threat=20 > one programming language different from another? Will be see voices that= =20 > ask for banning Rust packages in ::gentoo in the future? With the rising= =20 > popularity of Golang and Rust, we will (hopefully) only ever see an=20 > increase of such packages in ::gentoo. And most existing packages in=20 > this category will at best keep their dependency count constant, but are= =20 > also likely to accumulate further dependencies over time. I tend to agree with you honestly. I worked with Zac to come up with a different proposal which would allow upstream tooling for all languages that do this to work, but so far it is meeting resistance [1]. I will go back and add more information to that bug, but it will be later today before I can do that. I want to develop a poc to answer the statement that these would be live ebuilds if we allowed that. > And quite frankly, I don't see a problem with "large" Manifests and/or=20 > ebuilds. Yes, it means our FTPs are hosting many files, in some cases=20 > even many small files. And yes, it means that in some cases ebuild=20 > parsing takes a bit longer. But I spoke with a few developers in the=20 > past few months and was not presented with any real world issues that=20 > EGO_SUM caused. If someone wants to fill in here, then now is a good=20 > time to speak up. But my impression is that the arguments against=20 > EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am= =20 > wrong. I can't name any specific examples at the moment, but I have gotten some complaints about how long it takes to download and build go packages with hundreds of dependencies. Other than that, I'm not the one who voiced the problem originally, so we definitely need others to speak up. William [1] https://bugs.gentoo.org/833567 --z/ioP4Uxf3NSI9ZI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCYzcP3QAKCRBuVBb0MMRl OCi0AJ9hmtcBzomhfmP0elcD9vEK/g3/7gCgqkim1mu8vZepVqHDpJIoez3Ah8k= =D3M6 -----END PGP SIGNATURE----- --z/ioP4Uxf3NSI9ZI--