How to stop EBUILD performing premerge checks [SOLVED]

[mounty1]

It's well known that you can use I_KNOW_WHAT_I_AM_DOING=1 to stop emerge from performing checks.

emerge is a front-end for ebuild.

How do you prevent ebuild whateverthepackage.ebuild compile from performing the checks? I_KNOW_WHAT_I_AM_DOING=1 doesn't do it. I.e., how does emerge invoke ebuild when the env. var be set?

I need this because on one machine, emerge chromium just dies for some reason and the workaround is repeatedly to run ebuild chromium-version.ebuild compile. Yes I know it would be nice to find out why but I just don't have time or interest in fixing crappy little build problems.

The check is failing because /var/tmp/portage is a 32 GiB file system, chromium is taking 16 GiB so the check for 19 GiB free space is failing. I tried mounting an empty file system at /var/tmp/portage/www-client/chromium-blah/temp/2 (so that in fact there is 19 GiB free under .../temp) but the test was written by Microsoft and fails anyway, no doubt by trying to be too clever and failing.

So to repeat the question: how do you prevent ebuild whateverthepackage.ebuild compile from performing the checks?
_________________
Michael Mounteney

[CaptainBlood]

[Genone]

Space checks are performed by the check-reqs eclass. Skimming over that, looks like you can set CHECKREQS_DONOTHING to any value which will then bypass the die() call (the check is still performed and you'll get the message, but execution will continue).

Also I_KNOW_WHAT_I_AM_DOING is not a real thing, there are zero references to it in portage itself (some ebuilds or scripts might reference it, but that's just random then).

[wjb]

You can use package.env to tweak builds for individual packages, Gentoo Wiki: /etc/portage/package.env

So you could change MAKEOPTS to use less cores for chromium, which should reduce the RAM requirements - hopefully to something that will pass the check.

Or modify an ebuild function.

[logrusx]

[CaptainBlood]

[Hu]

www-client/chromium is a Gentoo Portage package which, like all Portage packages, will be built in a directory under PORTAGE_TMPDIR, which defaults to /var/tmp/portage. OP's problem then is that the artifacts from the first failed build consume disk space and make the build area look "too small" because the check assumes that the ebuild is not yet using any space, and that unpacking and building will consume space. In OP's case, unpacking has been done and will not be repeated, so the space consumed by source files does not need to be consumed again. Some amount of compilation has been done before the failure, so some build artifacts exist and consume space, and will not be duplicated by resuming the build.

That comment about the test by Microsoft seems wrong to me. OP seems to be asking about a Gentoo Portage safety check, not something from the upstream project.

For some purposes, which may or may not include the one about which the OP is asking, Portage restores the environment from the initial build when processing the resumption. This may (note: I have not checked this!) mean that the override environment variable needs to be set in the first call to emerge, so that it is present in the restored environment that the later manual ebuild sets up. If I am right, which I may not be, setting the override variable only on the attempted ebuild resumption will not propagate into the eclass, and therefore will have no effect.

[mounty1]

[mounty1]

[logrusx]

Judging by the following:

[CaptainBlood]