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