Dear pkgsrc users and developers,

the pkgsrc guide mentions the pkglint utility that can be used to check 
for common bugs in packages. If you should not know pkglint yet, I can 
understand that pretty well. Even four months ago pkglint had printed so 
many bogus messages that it was hard to tell what was really wrong with 
a package. During the last 18 months I have put quite some work into 
pkglint, and I think it has become much more usable than ever before. To 
give you a comparison, this is a typical pkglint output that you may 
have seen in July 2005:

roland@baccf5ee:~/proj/pkgsrc/archivers/php-bz2 > pkglint
FATAL: Extra item "MODNAME" placed in the DISTNAME section.
FATAL: Extra item "COMMENT" placed in the DISTNAME section.
FATAL: DISTNAME has to be there.
WARN: no MASTER_SITES or DYNAMIC_MASTER_SITES found. Is this ok?
FATAL: PKGNAME, which is derived from DISTNAME, must come with version 
number, l...
FATAL: Extra item "USE_PHP_EXT_PATCHES" placed in the MAINTAINER section.
WARN: Please add HOMEPAGE if the package has one.
FATAL: Please add a short COMMENT describing the package.
FATAL: No MAINTAINER listed in Makefile.
WARN: "DISTNAME" has to appear earlier.
WARN: "PKGNAME" has to appear earlier.
WARN: "MASTER_SITES" has to appear earlier.
WARN: "EXTRACT_SUFX" has to appear earlier.
WARN: "HOMEPAGE" has to appear earlier.

In the last four months I have reduced the number of false positive 
warnings dramatically. Because many packages then passed the pkglint 
test without errors or warnings, I have added some new warnings that I 
felt were useful. Mostly I have added such warnings after discovering 
that pkgsrc did not behave as I expected it to do. I have also added 
some new features to pkglint, for example scanning directories 
recursively. An example is:

roland@baccf5ee:~/proj/pkgsrc/archivers > pkglint -r
WARN: afio/Makefile:10: COMMENT should start with a capital letter.
WARN: bzip2/builtin.mk:6: Found absolute pathname: /usr/include/bzlib.h
ERROR: bzip2/builtin.mk:50: Variable names starting with an underscore 
are reserved for internal pkgsrc use.
WARN: mousetar/Makefile:11: COMMENT should start with a capital letter.
WARN: pax/Makefile:19: Definition of NO_PACKAGE is deprecated. Don't use 
it to enforce license restrictions.
WARN: rar/Makefile:23--36: Found absolute pathname: /$$KERNEL
WARN: rar/Makefile:23--36: Found absolute pathname: /$$KERNEL
WARN: rar/Makefile:23--36: Found absolute pathname: /$$KERNEL
WARN: rar-linux/Makefile:16--17: Unknown hardware architecture: i[3-6]86
WARN: unace22/Makefile:20--21: Unknown hardware architecture: i[3-6]86
1 errors and 9 warnings found.

Compared to the output from July, much has changed. All warnings and 
errors are now prefixed with a filename (and a line number if 
appropriate). This makes finding the causes of the warnings pretty easy.

Now you know where your package might have bugs, but perhaps you don't 
know why pkglint is complaining at all. Therefore I have added the 
--explain option (which can be abbreviated as -e).

roland@baccf5ee:~/proj/pkgsrc/archivers > pkglint -e bzip2
WARN: bzip2/builtin.mk:6: Found absolute pathname: /usr/include/bzlib.h
       Absolute pathnames are often an indicator for unportable code. As
       pkgsrc aims to be a portable system, absolute pathnames should be
       avoided whenever possible.
ERROR: bzip2/builtin.mk:50: Variable names starting with an underscore 
are reserved for internal pkgsrc use.
1 errors and 1 warnings found.

 From this example you can see that not all warnings have explanations 
yet. The explanations are a very recent feature of pkglint, so if you 
need an explanation for some warning, just send me a mail and I'll add it.

You should also send me a mail if you encounter any problem that can be 
checked by just looking at the files of the package. Or if you find some 
code or variables in a package that you simply don't understand or which 
looks like a bug, please tell me. In the last few years, the pkgsrc 
infrastructure has changed in so many places that most packages don't 
yet make use of the new features. This results in superfluous code. (For 
example, some packages are still trying to modify /etc/shells directly 
instead of using the PKG_INSTALL framework, which takes care of that.)

So please have a look at some packages, at least the ones you are 
maintaining, run pkglint for them and check if the warnings make sense. 
If they do, please fix them. If they don't, please tell me. If you are 
unsure, ask on the tech-pkg mailing list. Most probably other developers 
have similar problems.

Thanks for listening,

Roland