1 |
On Sat, Oct 01, 2022 at 07:21:13PM +0200, Florian Schmaus wrote: |
2 |
> On 01/10/2022 18.36, Ulrich Mueller wrote: |
3 |
> >>>>>> On Sat, 01 Oct 2022, Florian Schmaus wrote: |
4 |
> > |
5 |
> >> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It |
6 |
> >> appears that the ebuild had more than 6000 entries in SRC_URI [1], |
7 |
> > |
8 |
> > That includes double counting and must be divided by the number of |
9 |
> > developers in TEXLIVE_DEVS. AFAICS that number was two in 2020. So 3000 |
10 |
> > is more realistic as a number there. |
11 |
> |
12 |
> That may be very well the case. I'd appreciate if you would elaborate on |
13 |
> the double counting. If someone knows a good and easy way to compute A |
14 |
> for an ebuild, then please let me know. That would help to get more |
15 |
> meaningful data. |
16 |
> |
17 |
> |
18 |
> >> from which A is generated from. Hence even a EGO_SUM limit of 3000 |
19 |
> >> entries should provide enough safety margin to avoid any Golang ebuild |
20 |
> >> running into this. |
21 |
> > |
22 |
> > See above, with 3000 entries there may be zero safety margin. It also |
23 |
> > depends on total filename length, because the limit is the Linux |
24 |
> > kernel's MAX_ARG_STRLEN (which is 128 KiB). |
25 |
> |
26 |
> Of course, this is a rough estimation assuming that the filename length |
27 |
> is roughly the same on average. That said, my proposed limit for EGO_SUM |
28 |
> is 1500, which is still half of 3000 and should still provide enough |
29 |
> safety margin. |
30 |
|
31 |
Since EGO_SUM_SRC_URI is the variable that gets added to SRC_URI, I |
32 |
would rather put the limitation there instead of EGO_SUM if we do end up |
33 |
keeping this. |
34 |
|
35 |
William |