Todd Vierling wrote:
> On Mon, 25 Apr 2005, Johnny Lam wrote:
> 
>>pam.buildlink3.mk is meant to be included if you really want PAM.  If the
>>package can conditionally use PAM, then the package should be made to support
>>"PAM" in PKG_OPTIONS, and to include pam.buildlink3.mk if it is there.  If
>>PAM_TYPE takes the value "none", then it causes package builds to fail by
>>design.
> 
> I didn't suggest setting PAM_TYPE to "none"; rather, I'm taking the
> perspective of other smoke-if-you've-got-'em bl3 files that *return* "none"
> if the desired feature is unavailable.  Think pthread.buildlink3.mk without
> the "require" option being set before inclusion.
> 
> That way you can always include pam.buildlink3.mk without
> OS-conditionalizing a crapload of packages, and conditionalize the package
> on the *return value* "none" to indicate no PAM is available and should be
> disabled in the package.
> 
> There's no other sane way, as I see it, to turn on PAM by default --
> conditionalizing by OS in lots of package is just Wrong.

The point I was making is that if you include pam.buildlink3.mk, and no 
PAM implementation is available, then it doesn't return a PAM_TYPE of 
"none" -- it causes the package to fail building via PKG_FAIL_REASON. 
If pam.buildlink3.mk is included, then you actually want PAM -- you 
can't include pam.buildlink3.mk and check whether PAM_TYPE is "none".

If you have a package that can be built with or without PAM, then it 
should be made to take "PAM" in PKG_OPTIONS, and allow the user to 
specify it either positively or negatively in /etc/mk.conf.  We can, of 
course, provide good defaults for particular operating systems, e.g. on 
Linux, FreeBSD, Solaris, or NetBSD>=2.0, default to 
PKG_DEFAULT_OPTIONS+=PAM.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>