public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Florian Schmaus <flow@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, Sam James <sam@gentoo.org>
Subject: Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Date: Sat, 08 Jul 2023 22:21:30 +0100	[thread overview]
Message-ID: <87zg46drla.fsf@gentoo.org> (raw)
In-Reply-To: <10b30fd5-299d-e26e-5abf-1507c9e59305@gentoo.org>

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


Florian Schmaus <flow@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
> On 30/06/2023 10.22, Sam James wrote:
>> 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:
>>>> 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.
>
> It is not as easy as merely copying existing portage code into
> pkgcheck (unless I am missing something).
>

That's why I said "in terms of the metrics".

> I've talked to arthurzam, and there appears to be a .environment file
> created by pkgcheck, which we could use to approximate the exported
> environment.
>
> Another option would be to have pkgcheck count the EGO_SUM
> entries. The tree-sitter API for Bash, which pkgcheck already uses,
> seems to allow for that. But that would be different from the check in
> portage. Although, IMHO, counting EGO_SUM entries would be sufficient.

Right.

>
>
>> 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.
>
> So pkgcheck counting EGO_SUM entries would be sufficient for the
> purpose of having a static check that notices if the ebuild would
> likely run into the environment limit?
>

If you check it actually fires in some of the old broken scenarios
(see Bugzilla), then yes. But I'd be interested in your thoughts on
radhermit's reply (please reply there).

> To find a common compromise, I would possibly invest my time in
> developing such a test. Even though I do not deem such a check a
> strict prerequisite to reintroduce EGO_SUM.

Yes, you've made clear you disagree.

>
>
>>> 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.
>
> Talking about "reliably installable" makes it sound to me like there
> are cases where installing a EGO_SUM-based package sometimes works and
> sometimes not. But the kernel-limit is fixed and not even
> configurable, besides, of course patching the source (and in the
> absence of architectures with a page size below 4 KiB) [1].
>

ulm's reply notes that this is a limitation in the Linux kernel, so I
have no idea why musl tinderboxes seemed to disproportionately hit these
issues and I assume one of us either missing something or it was just
a crazy fluke.

> Any developer testing whether or notan ebuild is installable would
> become immediately aware if the ebuild runs into the environment
> limit, or not.
>

This clearly didn't happen with the previous examples (see what I said
above too), as there were times when they installed for some people, but
not in CI/tinderboxes. I don't know why and it merits investigation.

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

  parent reply	other threads:[~2023-07-08 21:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C>
     [not found] ` <be450641-94ff-a0d9-51da-3a7a3abcc6c7@gentoo.org>
     [not found]   ` <b7309a3f-2980-b390-a16a-0518cce1da75@gentoo.org>
     [not found]     ` <87y1k33aoy.fsf@gentoo.org>
2023-06-30  8:15       ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-06-30  8:22         ` Sam James
2023-06-30  9:38           ` Tim Harder
2023-06-30 11:33             ` Eray Aslan
2023-07-03 10:17               ` Florian Schmaus
2023-07-04  7:13                 ` Tim Harder
2023-07-04 10:44                   ` Gerion Entrup
2023-07-04 21:56                     ` Robin H. Johnson
2023-07-04 23:09                       ` Oskari Pirhonen
2023-07-05 18:40                         ` Gerion Entrup
2023-07-05 19:32                           ` Rich Freeman
2023-07-06  2:48                           ` Oskari Pirhonen
2023-07-06  6:09                   ` Zoltan Puskas
2023-07-06 19:46                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open Hank Leininger
2023-07-08 20:49                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Sam James
2023-07-03 10:17           ` Florian Schmaus
2023-07-03 11:12             ` [gentoo-dev] EGO_SUM Ulrich Mueller
2023-07-08 21:21             ` Sam James [this message]
     [not found]     ` <cdf5ddb7-8f65-74cf-5594-3e3eec86c915@gentoo.org>
     [not found]       ` <1913d3c2-5f54-acea-0ed3-930371ea1884@gentoo.org>
     [not found]         ` <CAAr7Pr9+zq2NV=7zhj5e+4LWOmNavCrfMstNTqkthk5uxQVNtg@mail.gmail.com>
2023-07-14  7:14           ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: Re: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-07-14  7:33             ` Sam James
2023-07-14  8:19               ` Sam James
2023-07-14  9:07               ` Florian Schmaus
2023-07-14  8:39             ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees Ulrich Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zg46drla.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=flow@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox