From owner-freebsd-ports@FreeBSD.ORG Tue Aug 30 11:09:49 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A8A1065672 for ; Tue, 30 Aug 2011 11:09:49 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 461918FC0A for ; Tue, 30 Aug 2011 11:09:48 +0000 (UTC) Received: (qmail invoked by alias); 30 Aug 2011 11:09:47 -0000 Received: from g227000177.adsl.alicedsl.de (EHLO apollo.emma.line.org) [92.227.0.177] by mail.gmx.net (mp066) with SMTP; 30 Aug 2011 13:09:47 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1/S9WxqVsHS3et9FLbeF+YY8sB8WC4YmtEjg1wp/O vCvgoALwmLDMcP Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 3075123CF4F for ; Tue, 30 Aug 2011 13:09:46 +0200 (CEST) Message-ID: <4E5CC4FA.8000302@gmx.de> Date: Tue, 30 Aug 2011 13:09:46 +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> <4E5B5E89.3000700@FreeBSD.org> <20110830102829.GN2084@pcfw2> In-Reply-To: <20110830102829.GN2084@pcfw2> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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 11:09:49 -0000 Am 30.08.2011 12:28, schrieb Frank Wall: > On Mon, Aug 29, 2011 at 11:40:25AM +0200, Matthias Andree wrote: >> 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. > > I don't think that this is the right way to go. You are forcing > the user to rethink his past decision(s). Why would I want to do this? Because you must, the former default configuration, even if you've acknowledged it as an informed decision you've made, no longer works. > The user decided to go a specific path by initially choosing a > specific set of OPTIONs. We *must* assume that the user had good > reasons to do so. We should *not* assume the user has no idea what > he's doing and needs to be guided. The latter would make make the > update process just more complicated. The point is, most users just agree to the defaults, and in that situation, there is reason to re-prompt. One might argue that we don't need to reprompt if the new default matches the old configuration, but the OPTIONS framework currently doesn't know "user set this deliberately" or "user just stuck to the defaults".