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).

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.


> 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?

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.


>> 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].

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

That said, static code checks are always preferable over dynamic ones.

- Flow


1: 
https://elixir.bootlin.com/linux/v6.4.1/source/include/uapi/linux/binfmts.h#L15