From owner-freebsd-ports@FreeBSD.ORG Mon Mar 25 20:44:51 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85CDCFFB; Mon, 25 Mar 2013 20:44:51 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id DF1F7FB1; Mon, 25 Mar 2013 20:44:50 +0000 (UTC) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id AE9248B143C; Mon, 25 Mar 2013 21:44:49 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -100.963 X-Spam-Level: X-Spam-Status: No, score=-100.963 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=0.037, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id 5EIWaxoMPHZe; Mon, 25 Mar 2013 21:44:48 +0100 (CET) Received: from [192.168.100.31] (p54B0A677.dip.t-dialin.net [84.176.166.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id 0BB648B143B; Mon, 25 Mar 2013 21:44:48 +0100 (CET) Message-ID: <5150B75F.6030908@executive-computing.de> Date: Mon, 25 Mar 2013 21:45:19 +0100 From: Marco Steinbach User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: OPTIONSng: Overide options in /var/db/ports/*/options ? References: <5145B415.80303@executive-computing.de> <5145C9DC.6010300@infracaninophile.co.uk> <5145E47D.4050201@executive-computing.de> <51460B2C.6080500@executive-computing.de> <20130317184927.GF72627@ithaqua.etoilebsd.net> <5146213E.3080005@executive-computing.de> In-Reply-To: <5146213E.3080005@executive-computing.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports Mailing List X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:44:51 -0000 Marco Steinbach wrote on 17.03.2013 21:02: > Baptiste Daroussin wrote on 17.03.2013 19:49: >> On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote: >>> Chris Rees wrote on 17.03.2013 17:15: >>>> On 17 Mar 2013 15:45, "Marco Steinbach" >>>> wrote: >>>>> Matthew Seaman wrote on 17.03.2013 14:49: >>>>> >>>>>> On 17/03/2013 12:16, Marco Steinbach wrote: >>>>>>> Hi, >>>>>>> >>>>>>> is there a way to overide options stored in /var/db/ports/*/options, >>>>>>> basically getting back the pre-OPTIONSng behaviour of being able to >>>>>>> overide port options in /etc/make.conf ? >>>>>>> >>>>>>> Before OPTIONSng was introduced, I was able to specify options in >>>>>>> /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, >>>>>>> WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency >>>>>>> of that >>>>>>> option in any port (or just specific ones, by e.g. checking >>>>>>> .CURDIR), >>>>>>> regardless of the setting the ports option file contained. >>>>>> Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in >>>>>> /etc/make.conf >>>>>> >>>>>> uniquename_SET= FOO BAR BAZ >>>>>> uniquename_UNSET= BLURFL >>>>>> >>>>>> will override the default settings in that port's Makefile for the >>>>>> FOO, >>>>>> BAR, BAZ and BLURFL options. >>>>>> >>>>>> Note: this won't override any settings you make from an options >>>>>> dialog. >>>>>> Might be a good idea to 'make rmconfig' if you only want to rely on >>>>>> /etc/make.conf >>>>> [...] >>>>> >>>>> Exactly my point. Currently, with OPTIONSng there seems to be no >>>>> way to >>>> overide anything in /var/db/ports/*/options. >>>>> I find it irritating, that I no longer can be sure about options in >>>> /etc/make.conf. I have to check/reconfigure to make sure. >>>>> As much as I like OPTIONSng (especially in combination with >>>> dialog4ports), this is one thing I'd very much like OPTIONSng to >>>> relearn: >>>> Enforce options regardless of what's in a ports options file. >>>> >>>> No, that's a bad idea. It's more confusing to have options not >>>> being set >>>> that are checked in the OPTIONS dialog. >>>> >>>> Setting those in make.conf sets defaults, and allows them to be >>>> overridden >>>> in individual ports. >>> Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of >>> what I willingly or accidentially configured in an OPTIONS dialog (or >>> is defaulted to in a ports Makefile), either because I didn't >>> understand the dependancy of a choice, I fat-fingered something or >>> someone helps me configuring something, and wants to make sure I get >>> it right: >>> >>> OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS >>> >>> Same goes for the complementary case of having options set forcibly, >>> either system-wide or per port: >>> >>> particularport_SET_FORCE= EXAMPLES DOCS >>> >>> I'd set these in /etc/make.conf, and be done for good. >>> >>> I have a local patch for that kind of behaviour, but wanted to check >>> for possible alternatives besides the beaten path, before bothering >>> bapt@. >>> >> >> The thing is half of people wants the /var/db/*/options to be the last >> word, the >> other half want the behaviour you are exposing, so getting a final >> word that >> will satisfy everyone is hard. > > I think the approach of having a choice between the two by allowing for > a new 'force it down the throat'-mechanism could serve both quite nicely. > > Existing /var/db/*/options files would still be read, but options can be > forcibly set or unset from /etc/make.conf, overriding the corresponding > options setting in options files. > >> I personnally really dislike /var/db/port/*/options and the dialog :). >> >> The new option framework has been design to: >> 1/ respect the same behaviour has it used to be before: >> /var/db/port/*/options >> has the final word. >> >> 2/ provide the ability to users to be able to tune the whole system in a >> consistent way. >> >> 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so >> that you >> can't save a option file by mistake. >> >> What we can probably do in the end is provide a new macro to totally >> in all >> cases ignore /var/db/port/*/options. >> >> Would that satisfy your needs? > > I'll recap the approaches: > > a) Options in /etc/make.conf only take precedence, if no > /var/db/ports/*/options file exists for a given port > > b) Options in /etc/make.conf always take precedence over options of the > same name read from /var/db/ports/*/options > > c) Options in /etc/make.conf are the only source of wisdom, anything in > /var/db/ports/*/options is ignored > > > a) is currently in place (*_SET, *_UNSET) > b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE) > c) probably comes closer to what you're suggesting > > I've attached my current workaround for b), where I simply duplicated > parts of your code in bsd.options.mk, adding a new suffix. Maybe this > further clarifies, what I'm currently missing. > > c) would come in handy, if you'd like to make sure nothing whatsoever > from /var/db/ports/*/options impacts a build. Baptiste, are you considering b) ? MfG CoCo