1 |
On Fri, Sep 30, 2022 at 04:53:39PM +0200, Florian Schmaus wrote: |
2 |
> On 30/09/2022 02.36, William Hubbs wrote: |
3 |
> > On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: |
4 |
> >>>>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: |
5 |
> >>> 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer |
6 |
> >>> maintains the package |
7 |
> >>> 3.) the number of EGO_SUM entries exceeds 1500 and a proxied |
8 |
> >>> maintainer maintains the package |
9 |
> >> |
10 |
> >> These numbers seem quite large, compared to the mean number of 3.4 |
11 |
> >> distfiles for packages in the Gentoo repository. (The median and the |
12 |
> >> 99-percentile are 1 and 22, respectively.) |
13 |
> |
14 |
> The numbers may appear large when compared to the whole tree, but I |
15 |
> think a fair comparison would be within the related programming language |
16 |
> ecosystem, e.g., Golang or Rust. |
17 |
> |
18 |
> For example, analyzing ::gentoo yields the following histogram for |
19 |
> 2022-01-01: |
20 |
> https://dev.gentoo.org/~flow/ego_sum_entries_histogram-2020-01-01.png |
21 |
> |
22 |
> |
23 |
> > To stay with your example, restic has a 300k manifest, multiple 30k+ |
24 |
> > ebuilds and897 distfiles. |
25 |
> > |
26 |
> > I'm thinking the limit would have to be much lower. Say, around 256 |
27 |
> > entries in EGO_SUM_SRC_URI. |
28 |
> |
29 |
> A limit of 256 appears to be to low to be of any use. It is slightly |
30 |
> above the 50th percentile, half of the packages could not use it. |
31 |
> |
32 |
> We have to realize that programming language ecosystems that only build |
33 |
> static binaries tend to produce software projects that have a large |
34 |
> number of dependencies. For example, app-misc/broot, a tool written in |
35 |
> Rust, has currently 310 entries in its Manifest. Why should we threat |
36 |
> one programming language different from another? Will be see voices that |
37 |
> ask for banning Rust packages in ::gentoo in the future? With the rising |
38 |
> popularity of Golang and Rust, we will (hopefully) only ever see an |
39 |
> increase of such packages in ::gentoo. And most existing packages in |
40 |
> this category will at best keep their dependency count constant, but are |
41 |
> also likely to accumulate further dependencies over time. |
42 |
|
43 |
I tend to agree with you honestly. I worked with Zac to come up with a |
44 |
different proposal which would allow upstream tooling for all languages |
45 |
that do this to work, but so far it is meeting resistance [1]. |
46 |
I will go back and add more information to that bug, but it will be later |
47 |
today before I can do that. I want to develop a poc to answer the |
48 |
statement that these would be live ebuilds if we allowed that. |
49 |
|
50 |
> And quite frankly, I don't see a problem with "large" Manifests and/or |
51 |
> ebuilds. Yes, it means our FTPs are hosting many files, in some cases |
52 |
> even many small files. And yes, it means that in some cases ebuild |
53 |
> parsing takes a bit longer. But I spoke with a few developers in the |
54 |
> past few months and was not presented with any real world issues that |
55 |
> EGO_SUM caused. If someone wants to fill in here, then now is a good |
56 |
> time to speak up. But my impression is that the arguments against |
57 |
> EGO_SUM are mostly of cosmetic nature. Again, please correct me if I am |
58 |
> wrong. |
59 |
|
60 |
I can't name any specific examples at the moment, but I have gotten some |
61 |
complaints about how long it takes to download and build go |
62 |
packages with hundreds of dependencies. |
63 |
|
64 |
Other than that, I'm not the one who voiced the problem originally, so |
65 |
we definitely need others to speak up. |
66 |
|
67 |
William |
68 |
|
69 |
[1] https://bugs.gentoo.org/833567 |