Lately, I've been going through some of the packages that I maintain
and changing the way that build options are specified.  The old way
was checking the values of, e.g. USE_CUPS, USE_PAM, USE_OPENLDAP,
KERBEROS, SASL_USE_GSSAPI, POSTFIX_USE_MYSQL, etc., and using those
values to control which options are built into the package.  I've been
changing my packages so that they take a single option, e.g. MUTT_OPTIONS,
POSTFIX_OPTIONS, OPENLDAP_OPTIONS, etc. that list several _optional_
modules that may be built into the package.  This one variable (per
package) can override a whole slew of global variables for that package.

In the new scheme, if you build pkgsrc/database/postfix, then if you
have:

	USE_SASL2=	YES
	USE_OPENLDAP=	YES

in your /etc/mk.conf, then Postfix will be built with SASLv2 and LDAP
table support.  However, suppose you don't want the LDAP support.  Then
you can do:

	# These stay untouched as they're used by other packages, e.g.
	# net/samba, databases/openldap, etc.
	#
	USE_SASL2=	YES
	USE_OPENLDAP=	YES

	# Explicitly list options for Postfix because we don't want all
	# of the global settings to apply.
	#
	POSTFIX_OPTIONS=	sasl

The benefit here is that you can still have global switches that apply
to all packages, e.g. USE_SASL2, USE_CUPS, etc., but on a per-package
basis, you can override them by setting a single variable.

Clearly, in the above example, you can do the same thing with package
variables like POSTFIX_USE_LDAP, POSTFIX_USE_SASL, etc., but I prefer
the single variable POSTFIX_OPTIONS because it makes for less clutter
in my /etc/mk.conf.  This is, of course, entirely subjective.

Any thoughts as to whether this is a worthwhile change?

	Thanks,

	-- Johnny Lam <jlam@NetBSD.org>