Stop using the system values as targets, and remove package derivation entries
where this is the case.
Switch the non-cross derivation case to have a target of "", rather than
matching the system, as this makes more sense, and is more consistent now that
the target values no longer match the system values.
Hardcode some more correct target values, and use these instead. Hopefully
this can be better integrated with Guix in the future.
This commit also includes a migration attempting to shrink some indexes.
If the file exists in the local store, then read it and add an entry to the
derivation_source_file_nars table. This will help to fill in the missing
entries, as currently entries are only added when the derivation source file
isn't in the database when the load new revision job runs.
It's more accurate to describe the specifics of the relevant data here through
terms like "matching" and "not matching", as a statement that something built
reproducibility needs to be made alongside the test conditions. So just say
that build outputs matched, or didn't match, as this is more descriptive of
the data available.
This effectively duplicates the behaviour in Guix for serializing derivations,
but this uses the database representation in the Guix Data Service, rather
than the records Guix uses.
Previously, they were nix-base32-string encoded, but the representation in the
derivations is base16, so it doesn't make sense to use a different
representation in the database.
Therefore, add some code that runs before the start of each job to convert the
data in the database. It was easier to do this in Guile with the existing
support for working with these bytevector representations. After some
migration period, the code for converting the old hashes can be removed.
Both in terms of the code fetching the data from the database, as well as the
formatted and detail outputs. This corrects an error in the formatted output
for derivations where inputs would be duplicated.
Rather than just counting builds where the derivation matches, select builds
based on the derivation outputs, which accounts for different but equivalent
derivations.
Derivations are effectively equivalent if they produce the same set of
outputs, which is possible because of the equivalence of fixed output
derivations. A fixed output derivation can be different, but equivalent,
because it produces the same fixed output.
To better allow tracking equivalent derivations, primarily to allow working
out what derivations might correspond to a build, store the sets of derivation
outputs, and which derivations they relate to.
Return integer values for ids, rather than strings (as this type is more
appropriate). Also, better parse the derivation arguments and environment
variables.
The first field is now a <derivation> record, rather than a store path for the
derivation.
It's probably not necessary to cope with two versions, but this is what I've
done currently.
Ludovic Courtès
Christopher Baines