Re: Running bulk builds for finding bugs in packages

[Roland Illig <roland.illig%gmx.de@localhost>]

On 30.05.2020 11:45, nia wrote:
> On Sat, May 30, 2020 at 10:34:47AM +0200, Roland Illig wrote:
> > A few days ago, I added a section to the pkgsrc guide containing ideas
> > for bulk builds with non-default configurations, to find packages that
> > don't stick to the pkgsrc conventions or to best practices.
> >
> > https://www.netbsd.org/docs/pkgsrc/bulk.html#bulk.var
> >
> > Did I miss any important build variants? Or are there any details that I
> > got wrong or that should have been explained better?
>
> Do we really want to turn package Makefiles into a document of every
> upstream code problem?

Hmmm, probably not.

I chose to do this for -Werror=char-subscripts because several C
programmers do not know how to use the <ctype.h> functions correctly.
Therefore I wanted to find out these packages and mark them, just to
know that _if_ they crash mysteriously, there's a hint somewhere.

My main goal of running that strict bulk build was to report these bugs
upstream, to have them fixed with the next update of the package.

A similar compiler flag is -Wimplicit-function-declaration, which would
catch a lot of old, rusty packages that declare their own string
functions or that don't include <unistd.h>.  Finding and fixing these is
a lot of work though, therefore I won't start that one.

> Werror is only viable if the exact compiler being used is predictable.
> I don't think Werror is suitable for pkgsrc.

For a general build, I agree completely.  This whole section is about
experimental bulk builds though, to find bugs.  And in these, I find it
acceptable to rely on a particular compiler.