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 388BE158009 for ; Fri, 30 Jun 2023 09:38:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 210D3E0931; Fri, 30 Jun 2023 09:38:15 +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 CBA49E092D for ; Fri, 30 Jun 2023 09:38:14 +0000 (UTC) Date: Fri, 30 Jun 2023 03:38:11 -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> 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-Disposition: inline In-Reply-To: <87jzvl2vzh.fsf@gentoo.org> X-Archives-Salt: 0528e62c-c7ee-4863-8079-d6c1cd50c57b X-Archives-Hash: 6977a5563c766930a19f5dfadcdea7d7 On 2023-06-30 Fri 02:22, Sam James wrote: > My position on this has been consistent: a check is needed to statically > determine when the environment size is too big. Copying the Portage > check into pkgcheck (in terms of the metrics) would satisfy this. > > That is, regardless of raw size, I'm asking for a calculation based on > the contents of EGO_SUM where, if exceeded, the package will not be > installable on some systems. You didn't have an issue implementing this > for Portage and I've mentioned this a bunch of times since, so I thought > it was clear what I was hoping to see. > > I would also like (which is not what I was referring to here) some > limit on the size, given that we already have a limit on the size of > ${FILESDIR}, but this is less of a concern for me given it's bounded > by the aforementioned environment size check. Why do we have to keep exporting the related variables that generally cause these size issues to the environment? I've asked as much on IRC multiple times (nearly every time this discussion has been brought up) and the answers I've gotten are some variation on "it's always been that way" or "not exporting them would break using commands as external programs" (e.g. calling via xargs). The first response isn't a great argument and the second response, while more valid, also feels less important than having a more minimalistic, exported environment that causes less issues like this one and others such as potentially affecting a package's build system in an unexpected fashion. See bug #721088 for the related discussion on environment variable exports. >From my stance, the spec should state that the only variables to be exported are ones already "semi-standard" and used externally of package manager internals in the expected fashion, which probably only includes HOME, TMPDIR, and maybe ROOT. This would of course currently break packages that use `xargs` while calling internal commands depending on some of those exported variables, but from a cursory glance at the gentoo repo, there aren't many ebuilds using that functionality and in general those that are could be written in an easier to understand fashion without using xargs. It should also be possible to proxy the required variables to those commands in various fashions without using the environment if using commands externally is extremely important to the few ebuild maintainers who make use of that functionality. In short, adding checks to portage and pkgcheck feels like a ill-suited workaround that foists hacking around the error onto users or developers due to a poor decision made decades ago on environment handling. Tim