Re: [PATCH] WIP: Output linters

[Eric Bavier]

On Wed, 13 Jul 2016 12:32:48 +0200
address@hidden (Ludovic Courtès) wrote:

> Hi!
> 
> address@hidden 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.

I agree with putting as many checks into build phases as we can.

Linter checks seem to be a good place for checking
issues that are non-fatal or of an "FYI" nature.  I would put in that
group checks for reproducibility issues, since currently we don't
consider non-reproducible builds to be a fatal issue (i.e. we don't
perform every build with --rounds=2). If we eventually declare that
every package needs to build cleanly with --rounds=2, then we could move
the relevant linter checks into build phases (to possibly catch issues
sooner in the build process), or remove the checks altogether (since
issues would presumably be caught with --rounds=2).

As an analogy: checks that would fall under Lintian's "Errors" type
should be a candidate for a build phase, and checks that would be
"Warnings" or "Info" should probably be in 'guix lint'.

https://lintian.debian.org/manual/section-2.3.html

`~Eric