- choose size/nosize in Config.
- use affinity or affinitystub
- move locker creation to State, so we can init cores right away.
- as core init has run, we can call DPB::Core->reap (event loop) while
processing size and build stats, so that the startup script may start
slightly earlier.
- setup more options in Config for Reporter to use.
- scaffolding in SubEngine/Build to be able to use affinity info right away
split it off, and provide a "stubbed" version of Heuristics::Size and
of Affinity that do nothing, to be used on one host configuration without
in-memory builds.
we're depending on junk to remove tagged stuff (and otherwise depend
won't run successfully).
This is different from "normal" junk, which does run after depend as
an optimization (makes little sense to remove packages we might be
reinstalling right away)
first tag we see will trigger a junk, unless we already
junked on that host during this run.
that way, we can forget whether we were building kde3 or kde4,
as we start with a "clean slate".
I could have junked at start, but this is much better, as it junks
"just in time" for the tag.
do the nojunk check in setup (so that we don't untaint if we're
not gonna run), and since we're testing in setup, use that to bypass
running altogether in such a case.
sorry landry, previous one was pretty bad... the reversed test result
is a stinker...
The moment when we're sure we're locked in uninstall
is the right moment to revisit tainted status...
not later, because if we do that in finalize, some tainted ports
may have finished building, and we may think we're untainted now.
as seen by landry@
Note also that setup runs in the main dpb process, so not concurrently with
the engine, and so the engine can safely check for tags right after setup,
even if pkg_delete has not finished, because by the time the port can lock
and reach depends, pkg_delete must have finished.
replace the dirty trick I did to reuse start with an intermediate
method that's more "reentrant" (use_core) by not fiddling with core's
status.
(bug appeared thanks to over-eager refactoring and shoddy code...)
between checksum and extract: that's when we're truely committed to
building the port there.
create the affinity markers at that point, and not sooner.
since we know whether we're building in memory, we can record that.
if we're building in-memory, always ask for size, since it's very very
fast.
special treatment for tagged ports on error: mark them as "cleaned" so
the host gets untainted eventually.
