prtverify(1)

NAME
prtverify - check CRUX ports for typical errors

SYNOPSIS
prtverify [options] <portdir> ...

DESCRIPTION
prtverify is a script that loads a bunch of gawk modules, each of them containing one or more tests.

The following tests are implemented:

port directory
     - contains all required files (Pkgfile .footprint .signature)
     - uncluttered by tarballs/index/svn files (-m clean-repo option)

Pkgfile
     - defines name, version, release, source
     - contains data in Description/Maintainer/URL headers
     - gives a valid email address for Maintainer
     - defines name variable in agreement with the directory name
     - defines release as a positive integer
     - does not attempt to override global pkgmk variables
     - uses only ASCII characters
     - lists dependencies without redundancy
     - all dependencies can be found in the specified collections (-m missing-deps option)
     - cd, rm commands do not leave the work directory

files/directories appearing in .footprint
     - not world writable
     - not junk
     - valid user and group
     - owned by root
     - not SUID/SGID
     - do not overwrite the directory permissions provided by core/filesystem
     - do not collide with files provided by other ports (-m file-conflict option)

OPTIONS

-l <loglevel>
    All tests are categorized into 4 levels, from FATAL to INFO, which can be used to adjust the output of prtverify. Set loglevel to 8 for INFO, 4 for WARN, 2 for ERROR and 1 for FATAL errors. Sum them up to show combined loglevels, e.g. 12 for WARN and INFO errors. The default is 15, which shows all error messages.

-m clean-repo
    If this mode is set, an additional test for invalid files like *.pkg.tar.gz or invalid directories like .svn is selected. Only sensible for clean repositories, of course.

-m missing-deps -c <path_to_collection> [-c <path_to_collection> ...]
    Adds a test for missing dependencies. The test takes the arguments set by the 'Depends on'-header and looks for a complying directory in the path specified by the -c option. Multiple -c options are allowed.

-m file-conflict -c <path_to_collection> [-c <path_to_collection> ...]
    Adds a test for file conflicts with the specified collections. The port's .footprint is compared with the list of all files owned by the ports in the paths passed with the -c option. Any overlapping files (not directories) are printed.

Note: the test is very time-consuming if you run it over a large number of collections !

WHITELIST
To avoid messages for errors which are known and accepted prtverify uses one or more whitelists to hide those. The whitelists are located at /usr/lib/prtverify/*.wl.

FILES
 /usr/lib/prtverify/*.awk
 /usr/lib/prtverify/prtverify.wl

COMPARISON WITH OTHER UTILITIES
prtverify only cares about $PWD if you pass relative paths as arguments. It will happily accept absolute pathnames instead. In either case, prtverify does not currently consult prt-get.conf(5) to see if the parent directory is an active collection; to consider the interdependencies among collections you must explicitly pass those directories with the -c option [1]. Any non-option argument to prtverify must be a directory, not a port name. prtverify then conducts its tests using a combination of filesystem reads and prt-get(8) processes.

Martin Opel's prtcheck(1) assumes that $PWD is the port's directory, does not accept any non-option arguments, and conducts all its tests by reading Pkgfile(5) and .signature from the current directory. Again there is no consulting of prt-get(8) to determine the full path of the port.

Han Boetes' findredundantdeps(1) does not care about $PWD at all; it relies entirely on prt-get(8) to obtain the necessary information. Hence findredundantdeps(1) will ignore any argument that cannot be found among the active collections (even if the argument is a directory under $PWD). The prtverify module 20_redundant_deps.awk (first distributed with prt-utils 1.3.2) has a similar limitation. Failure to find among the active collections a port listed in the "Depends on:" field will stop the traversal of that branch on the dependency tree (without issuing any warning on stderr), both for findredundantdeps(1) and prtverify. Hence you can trigger a false negative result by deactivating in prt-get.conf(5) the collection where the problematic dependency lives.

In its present design, the prtverify module 20_missing_deps.awk does not suffer from the same limitations of relying on prt-get(8). The user must manually specify (using option -c) the collections that are expected to contain all direct dependencies. Missing indirect dependencies are not considered by this module at all, but prt-get(8) can easily report their absence among the active collections (as well as the absence of direct dependencies). For example:

    prt-get depends webkitgtk | sed '1,/^-- missing/d'

With similar pipelines you can accomplish many of the "collection interdependency" tests that the prtverify modules perform. Because a pipeline started from a prt-get process takes its prtdir definitions from prt-get.conf(5), the user can achieve the equivalent flexibility of prtverify's -c option only by an awkward construction like:

    prt-get --config=<(sed -e '/prtdir/d; 3a prtdir /usr/ports/core\n prtdir /usr/ports/opt\n prtdir /usr/ports/xorg' /etc/prt-get.conf) depends webkitgtk | sed '1,/^-- missing/d'

The equivalent command using prtverify is almost as verbose, but easier for the human reader to interpret:

    prtverify -m missing-deps -c /usr/ports/core -c /usr/ports/opt -c /usr/ports/xorg webkitgtk

REFERENCES

[1] Future versions of prtverify might drop the requirement of the -c flag
    when the file-conflict or missing-deps mode is selected, falling back to the prtdir directives in prt-get.conf(5) or otherwise selecting some sensible defaults, e.g., the collection interdependencies hard-coded into Jose Beneyto's repoverify tool:
    https://lists.crux.nu/hyperkitty/list/crux-devel@lists.crux.nu/thread/2SMKZ63FBIKTP32VQUIMGCMTGEKCZUFV/

CREDITS
I'd like to thank Johannes Winkelmann for the initial idea for such a tool and for many suggestions and contributions.

AUTHORS
Juergen Daubert

John McQuah