Date: Thu, 13 Dec 2007 08:12:58 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Gordon M Tetlow <tetlowgm@mac.com>, Brooks Davis <brooks@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: Should libgssapi be hidden behind the MK_KERBEROS knob? Message-ID: <20071213051258.GA81366@team.vega.ru> In-Reply-To: <475B2BD1.7000303@FreeBSD.org> References: <4759DC08.9070600@FreeBSD.org> <20071208163857.GC91919@lor.one-eyed-alien.net> <B6258346-EB1D-451B-9D71-6497F3781344@mac.com> <475B2BD1.7000303@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
[ Sorry, I didn't notice this thread the commit. ]
On Sat, Dec 08, 2007 at 03:42:09PM -0800, Doug Barton wrote:
> Gordon M Tetlow wrote:
> >
> > On Dec 8, 2007, at 8:38 AM, Brooks Davis wrote:
> >
> >> On Fri, Dec 07, 2007 at 03:49:28PM -0800, Doug Barton wrote:
> >>> If there is a better list for this, don't hesitate to let me know.
> >>>
> >>> I use WITHOUT_KERBEROS=true in /etc/{make|src}.conf, since I don't
> >>> need or use it. However, this leads to a problem with building the
> >>> kdelibs3 port. The configure script looks for the presence of
> >>> libgssapi and the associated headers, and takes that to mean that
> >>> kerberos is available, and sets things up accordingly. This causes
> >>> the build to fail when it tries to actually link something to a
> >>> kerberos library.
> >>>
> >>> I realize that GSS can be used for other things besides kerberos, but
> >>> are we really losing anything by hiding them both under the same knob?
> >>> If the answer to that is yes, is there any objection to a WITHOUT_GSS
> >>> knob?
> >>
> >> We wouldn't loose anything today, but a without GSS knob makes more
> >> sense to me. There's at least one other GSS system in fairly wide use
> >> in the high performance computing world today.
> >
> > How about WITHOUT_KERBEROS implies WITHOUT_GSSAPI unless people
> > specifically ask for GSSAPI? Is that too obscure?
>
> That sounds totally reasonable. How does the attached look?
>
The new build options system was designed to be simple for
makefiles and users.
It is simple for makefiles in that they can check a particular
MK_* variable against "no" (only!) and don't bother to track
options interdependencies -- the latter is a task of bsd.own.mk.
This has been broken in this commit -- lib/Makefile looks
like this:
.if ${MK_KERBEROS} != "no"
_libgssapi= libgssapi
.else
.if ${MK_GSSAPI} == "yes"
_libgssapi= libgssapi
.endif
.endif
One of the goals of the new system was to avoid conditions like
this to appear in makefiles -- all the logic of setting the
MK_* variables (including tracking their interdependencies) should
be in bsd.own.mk. If MK_GSSAPI were set correctly, then lib/Makefile
would look like this:
.if ${MK_GSSAPI} != "no"
_libgssapi= libgssapi
.endif
Befor this change, there were two types of MK_* variables, those
defaulting to "yes" (majority), and those defaulting to "no".
There are also several options dependencies -- it works by
switching some options off when another option is switched off.
(This gets automatically documented in src.conf(5)). Plus
there's a small set of MK_*_SUPPORT variables that *defaulted*
to "yes" unless the corresponding MK_* option evaluated to "no",
in which case they are *forced* to "no".
This allows for the src.conf(5) manpage to be automatically
generated, showing only non-default options, and documenting
options interdependencies by the script.
Now the logic in lib/Makefile and a manpage are broken because
setting of MK_GSSAPI is broken -- it's set to "no" by default,
while the intent was to set its value to the value of
${MK_KERBEROS} unless it's set explicitly by WITH_GSSAPI /
WITHOUT_GSSAPI.
The logic in lib/Makefile is broken because WITHOUT_GSSAPI
simply doesn't have any effect, while all MK_* variables are
controllable by corresponding WITH_*/WITHOUT_* user-settable
knobs, modulo forcing some variables to "no" when their
dependencies are "no".
The manpage is broken because it misses some interesting facts,
e.g. that WITHOUT_CRYPT sets MK_CRYPT=no which in turn sets
MK_KERBEROS=no which in turn should set MK_GSSAPI=no.
While I have a patch that fixes all of the above bugs (and
it is committed by the time you read this), I have a proposal:
let's break this artificial dependency of MK_GSSAPI on
MK_KERBEROS, have a simple MK_GSSAPI option which defaults
to "yes", and have a WITHOUT_GSSAPI knob to turn it off.
Then we'd be back to a simple and normal behavior.
By having MK_GSSAPI default to the value of MK_KERBEROS we
introduce another type of MK_* variables defaulting to the
value of another MK_* variable. This is:
1) not necessary at the moment,
2) harder for users to understand, and
3) harder to implement and support (see my commit).
Cheers,
--
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071213051258.GA81366>