Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]


Florian Schmaus <flow@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
> [in reply to a gentoo-project@ post, but it was asked to continue this
> on gentoo-dev@]
>
> On 28/06/2023 16.46, Sam James wrote:
>> Florian Schmaus <flow@gentoo.org> writes:
>>> On 17/06/2023 10.37, Arthur Zamarin wrote:
>>>> I also want to nominate people who I feel contribute a lot to Gentoo and
>>>> I have a lot of interaction with (ordered by name, not priority):
>>>> […]
>>>> flow
>>>
>>> I apologize for the late reply, and thank you for the nomination. I am
>>> honored and accept.
>>>
>>> As many of you know, I am spending a lot of time on the EGO_SUM
>>> situation, as it is one of the most critical issues to solve.
>>>
>>> I have used the last few days to carefully consider whether a seat on
>>> the council is more harmful or beneficial to my efforts regarding
>>> EGO_SUM. On the one hand, council work means I have less time to
>>> improve the EGO_SUM situation. On the other hand, a seat in the
>>> council increases the probability of positively influencing Gentoo's
>>> future, also regarding EGO_SUM.
>>>
>> That's fine and it's great to see more people running!
>
> Excellent that we share this view. :)
>
>
>> But with regard to EGO_SUM: you didn't appear at the meeting where we discussed
>> your previous EGO_SUM proposal,
>
> Naively, as I am, I expected that the mailing list would be used for
> discussion and that the council meeting would be used chiefly for
> voting and intra-council discussion. And since the request to the
> council to vote on a concrete proposal was preceded by a
> multiple-week, if not month-long, mailing list discussion, I assumed
> that my presence in the council meeting was optional.
>
> Had I known that my presence was required, or that the absence in the
> meeting would be blamed on me afterward, I would have appeared if
> possible.

I'm not blaming you for anything. But you didn't speak in
#gentoo-council before the meeting (a few days before IIRC) when we
were discussing the problem, I pinged you during the meeting, and you
didn't appear there afterwards.

You also didn't seem to respond to the council decision (or
non-decision) in that meeting either, unless I've missed it.

It seems self-evident that discussion would happen in the meeting before
voting...? What am I misunderstanding?

We regularly discuss things before voting on them. Do you normally
observe council meetings? I don't think what we did in this instance
was at all unusual.

(Also: there's the issue of whether or not the council should really
be voting on overriding an eclass maintainer who would then be forced
to keep something working they don't want to. mgorny raised that.)

>
>
>> and questions remain unanswered on the
>> ML (why not implement a check in pkgcheck similar to what is in Portage,
>> for example)?
>
> On 2023-05-30 [1], I proposed a limit in the range of 2 to 1.5 MiB for
> the total package-directory size. I only care a little about the tool
> that checks this limit, but pkgcheck is an obvious choice. I also
> suggested that we review this policy once the number of Go packages
> has doubled or two years after this policy was established (whatever
> comes first).
>
> But I fear you may be referring to another kind of check. You may be
> talking about a check that forbids EGO_SUM in ::gentoo but allows it
> overlays.

My position on this has been consistent: a check is needed to statically
determine when the environment size is too big. Copying the Portage
check into pkgcheck (in terms of the metrics) would satisfy this.

That is, regardless of raw size, I'm asking for a calculation based on
the contents of EGO_SUM where, if exceeded, the package will not be
installable on some systems. You didn't have an issue implementing this
for Portage and I've mentioned this a bunch of times since, so I thought
it was clear what I was hoping to see.

I would also like (which is not what I was referring to here) some
limit on the size, given that we already have a limit on the size of
${FILESDIR}, but this is less of a concern for me given it's bounded
by the aforementioned environment size check.

>
> Intelligibly, EGO_SUM can be considered ugly. Compared to a
> traditional Gentoo package, EGO_SUM-based ones are larger. The same is
> true for Rust packages. However, looking at the bigger picture,
> EGO_SUM's advantages outweigh its disadvantages.
>

Again, am on record as being fine with the general EGO_SUM approach,
even if I wish we didn't need it, as I see it as inevitable for things
like yarn, .NET, and of course Rust as we already have it.

Just ideally not huge ones, and certainly not huge ones which then
aren't even reliably installable because of environment size.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]