On 02.05.23 21:45, Sam James wrote:
Florian Schmaus <f...@gentoo.org> writes:
On 27/04/2023 23.16, Sam James wrote:
Florian Schmaus <f...@gentoo.org> writes:
On 26/04/2023 18.12, Matt Turner wrote:
On Wed, Apr 26, 2023 at 11:31 AM Florian Schmaus <f...@gentoo.org> wrote:
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.
You're requesting the changes. It's on you to read the previous
threads and try to understand. It's not others' responsibilities to
justify the status quo to you, but tl;dr is Manifest files grew to
insane sizes for golang packages with many dependencies, and the
Manifest size is a cost all Gentoo users pay regardless of whether
they use the package.
I am sorry. I did try to understand the reasoning in the previous
threads. However, I do not conclude that the "cost" users must pay for
EGO_SUM justifies EGO_SUM's deprecation. It is the other way around:
EGO_SUM's advantages do not explain its deprecation, even if users
have to pay a cost.
You write that the "Manifest sizes grew to insane sizes"?
At which boundary does a package size, the total size of the package's
directory, become insane?
Disk space is cheap. Currently, ::gentoo, without metadata, is around
470 MiB. If you add 10 Go packages with a whopping 200 KiB each, then
this adds 2 MiB to that. I need someone to explain how this
constitutes an issue with disk space. Even if we add 100 Go packages,
probably roughly the number of Go packages we have in ::gentoo, then
those 20 MiB are not significant. Needless to say that the average
size of a Go package is less than the 200 KiB uses in this
calculation.
The numbers you've used here suggest you've missed some of the
big problematic cases from the past:
- https://bugs.gentoo.org/833478 (1.1MB manifest)
- https://bugs.gentoo.org/833477 (1.6MB manifest)
Thanks for pointing those bugs out.
But please allow me to clarify that I did not miss those "problematic"
cases from the past.
This kind of phrasing is the sort of thing which makes it seem like you
don't appreciate/acknowledge others' concerns.
I am genuinely sorry if my usage of "problematic" made it appear that I
do not appreciate the other's concerns. Like most people on this mailing
list, I appreciate everyone who cares about Gentoo and raises concerns.
I do, however, not share the concerns regarding EGO_SUM.
It is hard to share concerns based on rather abstract reasons—for
example, the portrayal of EGO_SUM as unfair.
It would be easier to share concerns if somebody gave concrete reasons
against EGO_SUM. For example, use cases that are no longer possible. Or
developers or users who are restricted in their work by EGO_SUM in a
relevant way.
But actual problems that currently speak against the use of EGO_SUM have
not surfaced.
I said problematic because it was clearly beyond what your worst-case
estimates were, i.e. far more than what you were saying would be a
large amount for the purposes of calculations.
Using the term "worst-case", even if I put it in quotes, probably got
people on the wrong track. I am sorry for that; my bad. It is, in
general, impossible even to approximate the worst-case size-increase of
::gentoo.
Our best chance is to use historical data to interpolate the future.
My back-of-the-envolope calculation was 256 Go-packages, with each
having 1 MiB. An analysis of the three on 2022-02-16, at the commit
right before Minikube and k3s were cleaned, showed that only five
packages out of 120 had larger package-directory sizes than one MiB.
256 Go-packages is roughly the number of Go-packages we have right now.
Assuming they all have a package-directory size of 1.6 MiB, the most
extensive EGO_SUM package the analysis yielded so far, we end up with
410 MiB.
The point you criticize was that a system able to handle the current
size of ::gentoo would also be able to manage an additional 256 MiB. The
point still stands if we exchange the 256 MiB with 410 MiB.
Furthermore, both numbers, 256 MiB and 410 MiB, are based on the
over-approximation that every EGO_SUM package uses 1.6 MiB, which is
almost certainly not the case. The mean package-directory size of a
EGO_SUM using package at 2022-02-16 was 280 KiB.
- Flow
