Should libgssapi be hidden behind the MK_KERBEROS knob?

[Ruslan Ermilov]

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 at FreeBSD.org
FreeBSD committer