Florian Schmaus <f...@gentoo.org> writes: > [[PGP Signed Part:Undecided]] > 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). >
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.
signature.asc
Description: PGP signature
