Date: Mon, 29 Aug 2011 11:40:25 +0200 From: Matthias Andree <mandree@FreeBSD.org> To: freebsd-ports@freebsd.org Cc: dinoex@freebsd.org Subject: Re: OPTIONS framework bug vs. SSL issues Message-ID: <4E5B5E89.3000700@FreeBSD.org> In-Reply-To: <4E5AA844.5030501@FreeBSD.org> References: <4E5A48AC.6050201@eskk.nu> <CADLo838TqZjGH__KNTu3A0wVEnX%2B225HFhBmiEjqj=456y6iag@mail.gmail.com> <4E5A7DAE.8090904@FreeBSD.org> <20110828174640.GC277@magic.hamla.org> <4E5AA844.5030501@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E5B5E89.3000700>