there is no mention of the available options that one could setup which may 
affect how a package is built (on netbsd's webpage). i didn't know about 
mk.conf.sample file 'til i read the Packages.txt. there for i suggest with 
each package, have a HELP file in the 'files' directory. when the user type 
'make help' that HELP file is displayed. in that HELP file, you can put the 
available options that a user can set in /etc/mk.conf and provide 
additional notes about the building of the package.

for instance, the openssl package didn't warn the user that there is 
already a system default 'openssl' command in /usr/bin which wasn't 
compiled with RSARef2. if the user was following the FAQ's on openssl's 
website and enter the first command to make a certificate, it will fail 
with some error saying 'genrsa' isn't recognized. it wasn't recognized 
cause when the user runs:

   $ openssl genrsa -des3 -out server.key 1024

it will use /usr/bin/openssl command instead of the one in /usr/pkg/bin.

still another example is the use of LDFLAGS in modssl. on my system, 
netbsd-1.4y/alpha, if i didn't explictly 'export LDFLAGS=-R/usr/pkg/lib' 
before typing 'make', the package will compile fine and install just fine. 
however when ap-ssl depends on modssl, the apache-ssl server will core dump 
when it can't find the run time libraries. again, LDFLAGS was listed in the 
Makefile, however, the ordinary user may not know it to set it. this case 
applies to the ap-php3 package as well (on my -current system).

by having a HELP file available via 'make help' it would help (no pun) 
inform the potential user what options they have before installing the 
package. with more informed users, the mailing list will get less 
questions. when packages are compiled the way the user wants, we have more 
happy users.