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 28B7A15800A for ; Fri, 14 Jul 2023 08:15:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E288E07FE; Fri, 14 Jul 2023 08:15:05 +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 BE8E2E07A7; Fri, 14 Jul 2023 08:15:04 +0000 (UTC) References: <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C> <1913d3c2-5f54-acea-0ed3-930371ea1884@gentoo.org> <170d28e2-5a3f-1dbd-90f5-30191d4c7f3c@gentoo.org> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: gentoo-project@lists.gentoo.org Cc: Alec Warner , gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Date: Fri, 14 Jul 2023 08:33:54 +0100 In-reply-to: <170d28e2-5a3f-1dbd-90f5-30191d4c7f3c@gentoo.org> Message-ID: <87lefi29kr.fsf@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 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d39d20c8-0b2c-41ef-8467-5361f1a91188 X-Archives-Hash: 437c4015ceeaa1cb247656e1dab3a62c Florian Schmaus writes: > [[PGP Signed Part:Undecided]] > Posted to gentoo-dev@ since we are now entering a technical discussion > again. > > For those who did not follow gentoo-project@, the previous posts include: > > https://marc.info/?l=3Dgentoo-project&m=3D168918875000738&w=3D2 > https://marc.info/?l=3Dgentoo-project&m=3D168881103930591&w=3D2 > > On 12/07/2023 21.28, Alec Warner wrote: >> On Wed, Jul 12, 2023 at 12:07=E2=80=AFPM Florian Schmaus wrote: >>> Apologies for not replying to everyone individually. >>> >>> I thank my fellow council candidates who took the time to reply to this >>> sensitive and obviously controversial matter. I understand that not >>> everyone feels comfortable taking a stance in this discussion. >>> >>> I asked the other council candidates about their opinion on EGO_SUM. >>> Unfortunately, some replies included only a rather shallow answer. A few >>> focused on criticism of my actions and how I approach the issue. Which >>> is obviously fine. I read it all and have empathy for everyone who feels >>> aggravated. You may or may not share the complaints. But let us focus on >>> the actual matter for a moment. >>> >>> Even the voices raised for a restricted reintroduction of EGO_SUM just >>> mention an abstract limit [1]. A concrete limit is not mentioned, >>> although I asked for it and provided my idea including specific limits. >>> Not knowing the concrete figures others have in mind makes it difficult >>> to find a compromise. For example, a fellow council candidate postulated >>> that it would be quicker for me to implement a limit-check in pkgcheck >>> than discuss EGO_SUM. I wish that were the case. Unfortunately it is I think this misrepresents my point. All I said was that a bound should be added matching what's in Portage right now. Please in future respond to me directly if you're going to claim something = about what I've said. > [...] > EGO_SUM affects two dimensions that could be limited/restricted: > A) the process environment, which may run into the Linux kernel > environment limit on exec(3) > B) the size of the package directory, where EGO_SUM affects the size of > ebuilds and the Manifest > > [...] > > A), however, is a different beast. There is undeniably a > kernel-enforced limit that we could hit due to an extremely large > EGO_SUM (among other things). However, the only bug report I know that > runs into this kernel limit was with texlive (bug #719202). The low > number of recorded bugs caused by the environment limit matches with > the fact that even the ebuild with the most EGO_SUM entries that I > ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052 > EGO_SUM entries, does *not* run into the environment limit. > I thought I'd gave you a list before, but maybe it was someone else. Anyway, a non-exhaustive list (I remember maybe two more but I got bored): * https://bugs.gentoo.org/829545 ("app-admin/vault-1.9.1 - find: The enviro= nment is too large for exec().") * https://bugs.gentoo.org/829684 ("app-metrics/prometheus-2.31.1 - find: Th= e environment is too large for exec().") * https://bugs.gentoo.org/830187 (you're CC'd on this) ("go lang ebuild: SR= C_URI too long that it causes "Argument list too long" error") * https://bugs.gentoo.org/831265 ("sys-cluster/minikube-1.24.0 - find: The = environment is too large for exec().") * a0be89b772474e3336d3de699d71482aa89d2444 ("app-emulation/nerdctl: drop 0.= 14.0") Other related bugs (as it's useful as a summary of where we are): * https://bugs.gentoo.org/540146 ("sys-apps/portage: limit no of exported v= ariables in EAPI 6") * https://bugs.gentoo.org/720180 ("sys-apps/portage: add support to delay e= xport of "A" variable until last moment") * https://bugs.gentoo.org/721088 ("[Future EAPI] Don't export A") * https://bugs.gentoo.org/833567 ("[Future EAPI] src_fetch_extra phase the = runs after src_unpack") I am not aware of a bug (yet?) for radhermit's suggestion wrt external helpers which is related but different to exporting fewer variables. thanks, sam