to predict how much disk space a package will require.
* Compute the output / closure size using the info stored in the
Nix database (rather than doing a slow "du").
releases as a dynamic view on the database was misguided, since
doing thing like adding a new job to a release set will invalidate
all old releases. So we rename release sets to views, and we'll
reintroduce releases as separate, static entities in the database.
the input build to be specified, as well as constraints on the
inputs of the inputs build. For instance, you can require that a
build has input `system = "i686-linux"'.
This is important when one binary build serves as an input to
another binary build. Obviously, we shouldn't pass a build on
i686-linux as an input to another on i686-darwin. Hence the
necessity for constraint.
The constraint are currently quite limited. What you really want to
say is that the "system" input of the other build has to match the
"system" input of this build. But those require a bit more work
since they introduce dependencies between inputs.
distinguish between jobs with the same name in different jobsets
(e.g. "trunk" vs "stdenv-branch" for Nixpkgs).
* Renamed the "attrName" field of Builds to "job".
* Renamed the "id" field of BuildSteps to "build".
