OPTIONSng: Overide options in /var/db/ports/*/options ?

Baptiste Daroussin bapt at FreeBSD.org
Mon Mar 25 21:23:46 UTC 2013


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 at 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 at .
> >>>
> >>
> >> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130325/fe10b4ff/attachment.sig>


More information about the freebsd-ports mailing list