Design of the global BROKENFILE considered broken

[Roland Illig <rillig%NetBSD.org@localhost>]

Hi,

I would like to add a new variable naming the file where the list of 
broken packages is built up during the bulk builds. The current state is 
not acceptable to me. (I know I'm a bit pedantic regarding these things. ;))

- The BROKENFILE variable name is used for giving two unrelated files 
the same name.

- The global BROKENFILE has an undocumented structure that differs from 
that of the package-specific BROKENFILEs, which are text/html (more or 
less). The current structure is " NERRORS PKGPATH/BROKENFILE BREAKS ". 
(Note the leading and trailing white-space.)

- The file format can be improved in two ways:

1. Instead of PKGPATH/BROKENFILE only PKGPATH should appear in the file. 
The only program that uses this information strips off the /BROKENFILE 
part before using the rest, so I don't see a reason for keeping it in 
the file.

2. Using the number of "*** Error" lines in the output as the first 
field of an entry looks somewhat arbitrary to me, and indeed that 
information is not evaluated by any program at all. The magic number -1 
means "some dependencies are broken".

The improved variable name and file format would be:

# File where a list of broken packages is built up during a bulk build.
# An entry in this file has the form "PKGPATH PHASE BREAKS", where
# PKGPATH has the form "category/package", PHASE is the pkgsrc phase
# in which the build failed or "depends" if some of the dependencies of
# the package were broken, and BREAKS is the number of packages that
# could possibly be built if this package were fixed.
TOPLEVEL_BROKENFILE?=   ${BULKFILESDIR}/.broken-pkgs${BULK_ID}

I chose the PHASE field because that's an information that I'm generally 
interested but which is currently not shown in the report. This field is 
also easier parseable by a human looking at the file, compared to the 
"number of \"*** Error\" lines" field that had been there before.

I also decided to drop the leading and trailing white-space in that 
file's format because requiring it is ugly.

Roland