Florian Schmaus <f...@gentoo.org> 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=gentoo-project&m=168918875000738&w=2 > https://marc.info/?l=gentoo-project&m=168881103930591&w=2 > > On 12/07/2023 21.28, Alec Warner wrote: >> On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus <f...@gentoo.org> 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 environment is too large for exec().") * https://bugs.gentoo.org/829684 ("app-metrics/prometheus-2.31.1 - find: The environment is too large for exec().") * https://bugs.gentoo.org/830187 (you're CC'd on this) ("go lang ebuild: SRC_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 variables in EAPI 6") * https://bugs.gentoo.org/720180 ("sys-apps/portage: add support to delay export 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
