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 04ECD15ACFB for ; Wed, 26 Apr 2023 20:53:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 799B6E08D1; Wed, 26 Apr 2023 20:53:45 +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 DEB04E08AA for ; Wed, 26 Apr 2023 20:53:44 +0000 (UTC) References: <49ce8700-6c96-9360-51cf-2a989f666752@gentoo.org> <29b2aa18-7498-ad42-757e-fdebad9fa5a5@gentoo.org> <87o7nd58by.fsf@gentoo.org> User-agent: mu4e 1.10.3; emacs 29.0.90 From: Sam James To: gentoo-dev@lists.gentoo.org Cc: council@gentoo.org, William Hubbs Subject: Re: [gentoo-dev] Re: EGO_SUM Date: Wed, 26 Apr 2023 21:51:52 +0100 In-reply-to: Message-ID: <87leiecqlo.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: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Archives-Salt: acfdb2d2-807b-47b5-a092-d63c47410678 X-Archives-Hash: f7857a3767d353fbf1e3547d53c0df56 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Florian Schmaus writes: > Hi Sam, > > thanks for your feedback. I am glad for everyone who engages in this > discussion and shares their views and new information. > > On 24/04/2023 22.28, Sam James wrote: >> Florian Schmaus writes: >> [CCing williamh@ as go-module.eclass & dev-lang/go maintainer.] >>=20 >>> I like to ask the Gentoo council to vote on whether EGO_SUM should be >>> reinstated ("un-deprecated") or not > In the various previous discussio= ns, the need >> for _some_ limit to be implemented (derived from EGO_SUM) was clear from >> the QA team and others. > > Asking to impose an artificial limit is based on the same unfounded > belief under which EGO_SUM was deprecated in the first place. I am > worried that if we follow this, then a potential next step is to argue > about adding packages to ::gentoo. > > >> Voting on the matter now would be reopening the issue which led EGO_SUM >> to be deprecated in the first place, with only a partial mitigation >> (the Portage warning). > > I am sorry, but I do not follow. I think this is partly because it is > not clear "what" (else) to mitigate. > > The discussion would be more productive if someone who is supporting > the EGO_SUM deprecation could rationally summarize the main arguments > why we deprecated EGO_SUM. I think Matt handled this in his reply. > > >> Any such limit should be supported by pkgcheck, allow using EGO_SUM >> for most packages, but exclude the pathological cases which we're >> unlikely to want in ::gentoo. >> (Limit-per-ebuild rather than per-package is one option of many, >> too.) > > As you probably noticed, I am not aware why we should impose such a > limit. Especially a per-package limit confines the ability to provide > the user with multiple versions of a package, which sometimes comes in > handy [1]. You added a check to Portage (thank you!) to warn when the environment size is too big. This is a runtime/dynamic check which we can't determine purely from the repository, so pkgcheck can't notice it. I would like pkgcheck to have an approximation of a too-large A in an ebuild (can use Manifest as a proxy if required) derived from the maximum environment size. I thought I'd communicated that need for the counterpart before. thanks, sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZEmPVF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDJCAD7Bwk5bwf/crCjKPuu36uDbMxyuZATDL/veAut GYkwj58A/3PLT4zDCsytIl62FybSb0cJt1VT+Aa2wQnkPuTC00EG =C34p -----END PGP SIGNATURE----- --=-=-=--