From owner-freebsd-ports@FreeBSD.ORG Tue Aug 30 10:03:42 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from apollo.emma.line.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 491DC1065670; Tue, 30 Aug 2011 10:03:42 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 2988D23CF4F; Mon, 29 Aug 2011 11:40:25 +0200 (CEST) Message-ID: <4E5B5E89.3000700@FreeBSD.org> Date: Mon, 29 Aug 2011 11:40:25 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Mnenhy/0.8.3 Thunderbird/3.1.12 MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <4E5A48AC.6050201@eskk.nu> <4E5A7DAE.8090904@FreeBSD.org> <20110828174640.GC277@magic.hamla.org> <4E5AA844.5030501@FreeBSD.org> In-Reply-To: <4E5AA844.5030501@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dinoex@freebsd.org Subject: Re: OPTIONS framework bug vs. SSL issues X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 10:03:42 -0000 Am 28.08.2011 22:42, schrieb Doug Barton: > On 8/28/2011 10:46 AM, Sahil Tandon wrote: >> On Sun, 2011-08-28 at 19:41:02 +0200, Matthias Andree wrote: >> >>> just a brain flash: bsd.port.mk currently re-prompts OPTIONS if >>> they've changed, for instance, through addition. >>> >>> Should we change this feature in b.p.mk so that it also re-prompt the >>> user when the defaults have changed? > > The way that (for example) portmaster works now is that if the user has > already answered the questions for that port they don't get the dialog > again unless a knob has been added or deleted. Personally I would find > it surprising to be presented with the dialog again if there were no > changes to the set of options. I wouldn't see a change in defaults in > this case since my answers are already going to be filled in. > > For this specific case I probably would have changed the language of the > gnutls option to make it clear that it needs to be un-selected, and > added a no-op OPTION to make sure that users saw the dialog. Euhm, while workable I don't like that approach. And I conclude that the way the OPTIONS system currently works has a serious shortcoming, in that it does not report changed defaults to the user. Basically in this situation ("default changed") we'd need to: 1. present the options form again 2. mention to the user that the default has changed 3. let him choose. What might help in the longer term is having sort of tree/four-state options, with "user-set to off" "user-set to on", "user does not care" and/or "user said go with whatever the default is". Arguably we might have wanted to kill the OPTIONS on cups* altogether, and waive the BROKEN tag this time Dirk, do we have any hints that the CUPS-refuses-GNUTLS will be resolved in the foreseeable future? If not, can we just bite the bullet and remove the OPTIONS and force OpenSSL builds even though it might cause license concerns deeper down the dependency tree?