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"
<c...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
