Date: Mon, 25 Mar 2013 21:45:19 +0100 From: Marco Steinbach <coco@executive-computing.de> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: FreeBSD Ports Mailing List <freebsd-ports@freebsd.org> Subject: Re: OPTIONSng: Overide options in /var/db/ports/*/options ? Message-ID: <5150B75F.6030908@executive-computing.de> In-Reply-To: <5146213E.3080005@executive-computing.de> References: <5145B415.80303@executive-computing.de> <5145C9DC.6010300@infracaninophile.co.uk> <5145E47D.4050201@executive-computing.de> <CADLo8399uthkGDPGQv8aV8hdOuBzcsczcdx1tv5KoWAQmCjVFA@mail.gmail.com> <51460B2C.6080500@executive-computing.de> <20130317184927.GF72627@ithaqua.etoilebsd.net> <5146213E.3080005@executive-computing.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >>>> <coco@executive-computing.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5150B75F.6030908>