Subject: *_OPTIONS for package options
To: None <tech-pkg@NetBSD.org>
From: Johnny C. Lam <jlam@NetBSD.org>
Date: 07/24/2004 05:08:16
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
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.
# Explicitly list options for Postfix because we don't want all
# of the global settings to apply.
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?
-- Johnny Lam <jlam@NetBSD.org>