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.

- Flow


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

Attachment: OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to