Subject: Re: PAM enabled by default in packages that support it?
To: Todd Vierling <firstname.lastname@example.org>
From: Johnny C. Lam <jlam@NetBSD.org>
Date: 04/25/2005 14:53:08
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
> 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
-- Johnny Lam <jlam@NetBSD.org>