From owner-freebsd-arch@FreeBSD.ORG Thu Dec 13 06:51:19 2007 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3AF16A420 for ; Thu, 13 Dec 2007 06:51:19 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 00EF313C467 for ; Thu, 13 Dec 2007 06:51:18 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=63082 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J2heD-000J8t-F5; Thu, 13 Dec 2007 06:34:17 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id lBD5Di5Y081435; Thu, 13 Dec 2007 08:13:59 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id lBD5DDn0081408; Thu, 13 Dec 2007 08:13:13 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Thu, 13 Dec 2007 08:12:58 +0300 From: Ruslan Ermilov To: Doug Barton Message-ID: <20071213051258.GA81366@team.vega.ru> References: <4759DC08.9070600@FreeBSD.org> <20071208163857.GC91919@lor.one-eyed-alien.net> <475B2BD1.7000303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475B2BD1.7000303@FreeBSD.org> X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Gordon M Tetlow , Brooks Davis , freebsd-arch@FreeBSD.org Subject: Re: Should libgssapi be hidden behind the MK_KERBEROS knob? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 06:51:19 -0000 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