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 9993815800D for ; Tue, 4 Jul 2023 07:13:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 06E59E0894; Tue, 4 Jul 2023 07:13:34 +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 C3913E087C for ; Tue, 4 Jul 2023 07:13:33 +0000 (UTC) Date: Tue, 4 Jul 2023 01:13:30 -0600 From: Tim Harder To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C> <87y1k33aoy.fsf@gentoo.org> <5b5e5a30-6fcc-7a9d-6c91-67d9a6a5c560@gentoo.org> <87jzvl2vzh.fsf@gentoo.org> <52703145-a284-30f3-aac8-69ed086a5f4a@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: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <52703145-a284-30f3-aac8-69ed086a5f4a@gentoo.org> X-Archives-Salt: b52879a9-4740-4aa0-a874-8096c97f2c64 X-Archives-Hash: 1af303bfba1d9677e19fae9fa8abb3bb On 2023-07-03 Mon 04:17, Florian Schmaus wrote: >On 30/06/2023 13.33, Eray Aslan wrote: >>On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: >>>Why do we have to keep exporting the related variables that generally >>>cause these size issues to the environment? >> >>I really do not want to make a +1 response but this is an excellent >>question that we need to answer before implementing EGO_SUM. > >Could you please discuss why you make the reintroduction of EGO_SUM >dependent on this question? Just to be clear, I don't particularly care about EGO_SUM enough to gate its reintroduction (and don't have any leverage to do so anyway). I'm just tired of the circular discussions around env issues that all seem to avoid actual fixes, catering instead to functionality used by a vanishingly small subset of ebuilds in the main repo that compels a certain design mostly due to how portage functioned before EAPI 0. Other than that, supporting EGO_SUM (or any other language ecosystem trending towards distro-unfriendly releases) is fine as long as devs are cognizant how the related global-scope eclass design affects everyone running or working on the raw repo. I hope devs continue leveraging the relatively recent benchmark tooling (and perhaps more future support) to improve their work. Along those lines, it could be nice to see sample benchmark data in commit messages for large, global-scope eclass work just to reinforce that it was taken into account. Tim