Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 725638 - Allow parallel builds to take size estimates into account
Summary: Allow parallel builds to take size estimates into account
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-27 15:42 UTC by Joe Breuer
Modified: 2020-05-28 01:59 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Breuer 2020-05-27 15:42:57 UTC
As part of a world upgrade, I had some pretty large (build time size) packages to upgrade: chromium, libreoffice, torbrowser, palemoon, qtwebengine, qtwebkit and a couple others.

emerge chose to parallelize builds of (all) those aforementioned packages, causing my double-digit GB (must've been around 20 GB free) /var/tmp to run out of space, breaking ALL those builds and necessitating significant time and some coddling to get those built properly.

I propose two possible / one building on the other solutions:

a) there is a maximum of one parallel build started per free GB of /var/tmp/portage space. In addition, there's a way for an ebuild to specify larger build space requirements (GB granularity would be fine IMO) which would be similarly honored. Those could take the place of per-package pre-build-script size checks as are done by some packages now.

b) similar to the time estimates used by genlop, max build directory sizes are tracked / logged some place and those (of previous versions) are used as a guesstimate, with some safety factor (x2, x1.5 or so). Falling back to something like (a) when there's no data from previous builds available.