Hello!
On Sat, 26 Aug 2006, Doug Barton wrote:
I've tried to use sysutils/portconf, but found that it still doesn't
give an universal solution:
I think we need to be careful what our expectations of "universal" are with
a ports tree as large, and a userbase as diverse, as what we have. However ...
Hmm, let me cite your letter in this thread:
=========================================================================
From [EMAIL PROTECTED] Wed Aug 23 23:56:09 2006
Date: Wed, 23 Aug 2006 13:51:52 -0700
From: Doug Barton <[EMAIL PROTECTED]>
To: Ruslan Ermilov <[EMAIL PROTECTED]>
Cc: Vivek Khera <[EMAIL PROTECTED]>, "Todorov @ Paladin" <[EMAIL PROTECTED]>,
freebsd-stable <freebsd-stable@freebsd.org>
Subject: Re: 5.5 to 6.1 upgrade
Ruslan Ermilov wrote:
On Tue, Aug 22, 2006 at 11:07:45PM +0300, Todorov @ Paladin wrote:
Also - why portupgrade is not always aware of
previously chosen options for a port build?
It depends. If options are OPTIONS (in the ports sense), they
are saved and independent of portupgrade. If options are
makefile options specified in pkgtools.conf, they are only
taken into accont if the port is (re)build explicitly; they
are not taken into account if a port is (re)built as a
dependency of another port. In plain text: if port B has
options in pkgtools.conf, and port A has B as its dependency,
and you portinstall/portupgrade A, B will be built (if needs
be) without pkgtools.conf options. Be careful.
sysutils/portconf does not have that limitation. If you specify flags using
that method, they will always be used.
FYI,
Doug
=========================================================================
So, one can mistakenly think that "always" here really means ALWAYS
(i.e., for every port). However many ports use that funny OPTIONS (in the
ports sense) which completely ignore make's WITH_xxx / WITHOUT_xxx
environment variables, so "always" isn't correct word here I suppose.
1) it doesn't work if /usr/ports is a link to another location.
Sure it does. You just have to be smarter about how you specify the triggers
in make.conf. :) I have the following:
.if !empty(.CURDIR:M/mnt/slave/space/ports*)
# Begin portconf settings
...
Works like a charm.
Sure this (changing the body of the "Do not touch these lines" block ;)
works! However portconf's +DISPLAY message doesn't even suggest that trigger
in /etc/make.conf should be changed according to the `realpath /usr/ports/`.
BTW, can this trigger line be changed in order to work in both standard case
(/usr/ports is a port directory itself) and case when /usr/ports is a symlink
to the actual port tree? I don't know make's language enough to embed
`realpath /usr/ports/` to the trigger, sorry.
2) it still doesn't affect OPTIONS (in the ports sense); try e.g. the
following:
If it's not working at all to start with (as you specified above), then this
additional example of brokenness is meaningless. Additionally, OPTIONS
ignores settings in the environment at all times to start with. It's easy
enough to test this for yourself by placing something in make.conf.
Yes, OPTIONS ignore settings in the make's environment, and it's confusing.
At least option's default could follow WITH_xxx / WITHOUT_xxx, so I'd
expect e.g. "SNMP support" to be checked when /etc/make.conf contains
WITH_SNMP=yes
To add even more confusion, OPTIONS _do_ obey shell's (not make's) environment
variables:
cd /usr/ports/net/quagga && WITH_SNMP=yes make rmconfig config
correctly checks "SNMP support"! So (at least, from consistency POV) I think
that OPTIONS should obey make's WITH_xxx / WITHOUT_xxx environment
variables in the same way as they obey shell's variables.
The more "perfect" solution, I think, would be to make those options (set
via both make's and shell's WITH_xxx / WITHOUT_xxx variables) unchangeable in
OPTIONS dialog (paint them grey as Windows does? Not so unreasonable I think).
So in the case when _all_ menu items have appropriate WITH_xxx / WITHOUT_xxx
settings, the entire menu dialog could be skipped and port installation could
be made unattended. Wouldn't that be nice?
hth,
Doug
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: [EMAIL PROTECTED]
nic-hdl: LYNX-RIPE
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
