From owner-freebsd-ports@FreeBSD.ORG Sat Jul 31 13:54:44 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA01616A4CE for ; Sat, 31 Jul 2004 13:54:44 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FF843D49 for ; Sat, 31 Jul 2004 13:54:43 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BquJf-000Nl0-Qt; Sat, 31 Jul 2004 15:54:30 +0200 Date: Sat, 31 Jul 2004 15:55:46 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Ion-Mihai Tetcu From: Oliver Eikemeier In-Reply-To: <20040731161132.099fae03@it.buh.tecnik93.com> Message-Id: <5293051E-E2F9-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: ports@freebsd.org cc: Radim Kolar Subject: Re: configuring ports via Makefile.local X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 13:54:44 -0000 Ion-Mihai Tetcu wrote: > On Sat, 31 Jul 2004 14:17:46 +0200 > Oliver Eikemeier wrote: > >> Ion-Mihai Tetcu wrote: >> >>> [...] >>>> I even want to be able to configure ports that have absolutely no >>>> support for optionsNG, by prasing the Makefile for WITH(OUT)_ >>>> tests Of course you will have limited funtionality, since no >>>> explanations of the options are available. Currently the >>>> development has been delayed, due to the localpkg breakage. >>> >>> Yes, a heads-up would have been nice. Does it make sense to produce >>> patches to convert ports without OPTIONS to OPTIONS now or one >>> should wait until optionsNG ? Does it makes sense to convert to >>> options at all? >> >> Hmmm... The stuff I'm developing is publicly available at >> devel/portmk. A heads-up makes only sense when decisions have been >> made, which is not the case. > > I was speaking about the localpkg change. Ah. We are discussing this on current@, there will be a heads-up when we have agreed on a way to proceed. > [...] >>> Any port that uses optionsNG should behave like before when a user >>>> choses to use other means than optionsNG to configure the port. So >>>> it's an optional feature, but not required. >>> >>> My want list for options ;) contains: >>> - have a way to output something to the user _before_ the options >>> blue screen >> >> What do you want to display? IMHO configuration should be a one-step >> process, perhaps with an optional help file. > > Yes. The aim is to be more user friendly. There is little screen space > so options descriptions are more that brief. Plus that I have to check > exclusive options not to be selected after exiting options screen, so > the user have to do a rmconfig if that happens; it would be easier just > to output "don't select X and Y in the same time". Some mechanism for ports to reject invalid configurations should be in place. And of course something like a list of possibilities to choose from. Unfortunately this implies that dialog(1) can't be used. -Oliver