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 409E2158094 for ; Sat, 1 Oct 2022 17:21:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E221AE0A5B; Sat, 1 Oct 2022 17:21:18 +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 8DB1FE0A45 for ; Sat, 1 Oct 2022 17:21:18 +0000 (UTC) Message-ID: Date: Sat, 1 Oct 2022 19:21:13 +0200 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [gentoo-dev] Proposal to undeprecate EGO_SUM Content-Language: en-US To: Ulrich Mueller Cc: gentoo-dev@lists.gentoo.org References: <20220613074411.341909-1-flow@gentoo.org> <82e86772-a727-2858-afc8-e08c46723e1e@gentoo.org> From: Florian Schmaus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: a34ee82e-7303-45d4-938d-49845f13139e X-Archives-Hash: c921b821005052af17cc3b258bd04347 On 01/10/2022 18.36, Ulrich Mueller wrote: >>>>>> On Sat, 01 Oct 2022, Florian Schmaus wrote: > >> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It >> appears that the ebuild had more than 6000 entries in SRC_URI [1], > > That includes double counting and must be divided by the number of > developers in TEXLIVE_DEVS. AFAICS that number was two in 2020. So 3000 > is more realistic as a number there. That may be very well the case. I'd appreciate if you would elaborate on the double counting. If someone knows a good and easy way to compute A for an ebuild, then please let me know. That would help to get more meaningful data. >> from which A is generated from. Hence even a EGO_SUM limit of 3000 >> entries should provide enough safety margin to avoid any Golang ebuild >> running into this. > > See above, with 3000 entries there may be zero safety margin. It also > depends on total filename length, because the limit is the Linux > kernel's MAX_ARG_STRLEN (which is 128 KiB). Of course, this is a rough estimation assuming that the filename length is roughly the same on average. That said, my proposed limit for EGO_SUM is 1500, which is still half of 3000 and should still provide enough safety margin. - Flow