Subject: make help
To: None <email@example.com>
From: Mocha <firstname.lastname@example.org>
Date: 05/23/2000 12:50:03
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