Hi! ericbav...@openmailbox.org skribis:
> The current patch just adds a simple check for the presence of build directory > strings in the output, which may affect build reproducibility across machines. > Other checks that might be useful might include checks: > > * for "recent" timestamps, which might indicate use of __DATE__ or `date`, > > * for presence of '.DIR' or other empty directories, > > * for proper placement of documentation, > > * for documentation that might best be moved to a "doc" output, or > > * for self-contained pkg-config files, etc. All good ideas! This reminds me that Taylan had posted a .pc file parser to check for dependencies that should be propagated; this could be used as one of the checks. > Any such checks obviously rely on the package outputs being in the store. On > the one hand both local builds and substitutes are expensive. But on the > other hand we'd like 'guix lint' to be run before someone submits a patch or > pushes their commits. Being a good submitter, they hopefully went through the > trouble to test that the package builds, so the package outputs are mostly > likely in the store anyhow, and 'guix lint' wouldn't have any extra work to > do. > > I'd like to hear from others whether they think this WIP has enough merit to > include in 'guix lint', and if so what other checks might be worth including. So far such checks were done as extra build phases: ‘validate-runpath’ and ‘validate-documentation-location’. The advantage is that they cannot be skipped unwillingly; the build succeeds if and only if all the checks passed. The downside is that adding or modifying such a phase leads to a full rebuild. Something that is both an advantage and a downside is that you get to test the rules on all the packages, so you can (have to :-)) make sure they work well. I think I prefer keeping such checks as build phases, although perhaps there are cases where this is inconvenient. WDYT? Thanks, Ludo’.
