On Wed, Jun 3, 2015 at 4:22 PM, Christian Bricart <christ...@bricart.de> wrote:
> Dear devs,
>
> i've just hit the constraint CHECKREQS_MEMORY=3G in
>>=www-client/chromium-44.* on a 2 GiB RAM machine.. (having additionally
> 5G Swap on SSD..)
>
> I personally doubt that check-reqs_memory() in the eclass should only
> check for *physical* rather than *virtual* RAM to fulfill this
> constraint and fail if unsatisfied.
>
> So my proposal would rather be:
>
> * $CHECKREQS_MEMORY<=pysical RAM -> ok
> * $CHECKREQS_MEMORY>pysical RAM && <= virtual RAM -> ewarn
> * $CHECKREQS_MEMORY>virtual RAM -> eerror (may still be overridden by
> ${I_KNOW_WHAT_I_AM_DOING} in check-reqs_output() )
>
> what do you think?
>The chromium build issue is a point of some contention; see the bug below. https://bugs.gentoo.org/show_bug.cgi?id=471810 I agree that it makes sense to check virtual memory. I guess that would be MemTotal + SwapTotal in /proc/meminfo. It would also probably make more sense to check available memory (MemAvailable + SwapFree). Maybe that should be implemented in a new function, like check-reqs_memory_available. I don't like your weird ewarn/eerror proposal. We should either fail, or not fail in check-reqs_pkg_pretend and check-reqs_pkg_setup. And the helper functions should continue to return a non-zero status on failure.
