- instead of seen/unseen, have an actual constructor. Instead, mark pkgpath
for which we wantinfo/wantbuild.
- only mark EXTRA dependencies as wantinfo. So the devel/haddock,no_deps
temporary error should be gone.
- since we have FLAVOR and SUBPACKAGE available, construct as much info as
we can during vars scanning (see handle_equivalences). This avoids about 150
path rescans during a full bulk. Also, grab the timing and logsizes from
equivalent files, so that most stuff should know show % all the time.
- tweak subdirlist to be a hash, and correctly add pkgpath_and_flavors to it.
That way, we rescan avahi pseudo flavors just once, and not four or five times.
dpb coalesces build dependencies over MULTI_PACKAGES: if we don't substract
from MULTI_PACKAGES, this can lead to bootstrap loops.
Case in point: sysutils/gamin, whose build relies on "no_server" to be
available as a dependency for glib2/gtk+2.
(but IGNORED stuff is properly kept as MULTI_PACKAGES, since it's mostly
intended to avoid strange arch errors)
- if there is no flavor in BUILD_PKGPATH, it's not necessarily the default,
make sure there's an empty flavor by appending a ,
- pass FLAVOR to dump-vars, so that eventually dpb can match "no flavor
specified" to "this is the default flavor", thus getting a bit smarter
(this should speed up the LISTING job by not traversing as many subdirs).
eventually.
- fetch all files
- ignore ignores
- specific builder that doesn't look at existing packages
currently: does not stop when fetch is finished, which is somewhat of the
remaining issue.
Also: change stats to store pid, to make sense of interleaved log files.
This is occasionally useful for pseudo-flavors: these do not get encoded
in the pkgpath, so taking (for instance) sqlports, this generates lines
which are later impossible to exploit based only on the fullpkgpath, as
opposed to fullpkgpath,flavor (which might contain the flavor twice, but
this is not an issue).
Fixes ruby 1.9 build with systrace now that we have these system calls.
The other new *at system calls need to have path restrictions and will
need further work so are still prevented for now (in those cases, the
supplied paths are *relative to a certain FD*, so we can't simply
examine supplied paths).
