On 30/06/2023 10.22, Sam James wrote:
Florian Schmaus <f...@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. - Flow1: https://elixir.bootlin.com/linux/v6.4.1/source/include/uapi/linux/binfmts.h#L15
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
