Date: Mon, 29 Apr 2013 22:34:38 +0200 From: Marco Steinbach <coco@executive-computing.de> To: FreeBSD Ports Mailing List <freebsd-ports@freebsd.org> Subject: Re: OPTIONSng: Overide options in /var/db/ports/*/options ? Message-ID: <517ED95E.9090907@executive-computing.de> In-Reply-To: <20130325212341.GC64932@ithaqua.etoilebsd.net> 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> <5150B75F.6030908@executive-computing.de> <20130325212341.GC64932@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Baptiste Daroussin wrote on 25.03.2013 22:23: > On Mon, Mar 25, 2013 at 09:45:19PM +0100, Marco Steinbach wrote: >> 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 > > I will definitly I need to review you patch and some others I recieved, just I > need to find time to do it. > > Thanks for reminding and for the patch. > > regards, > Bapt Baptiste found the time, reviewed and committed in ports r316825. Thank you :) MfG CoCo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?517ED95E.9090907>