5.5 to 6.1 upgrade

[Dmitry Pryanishnikov]

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 dougb at freebsd.org Wed Aug 23 23:56:09 2006
Date: Wed, 23 Aug 2006 13:51:52 -0700
From: Doug Barton <dougb at freebsd.org>
To: Ruslan Ermilov <ru at freebsd.org>
Cc: Vivek Khera <vivek at khera.org>, "Todorov @ Paladin" <todorov at paladin.bulgarpress.com>, freebsd-stable <freebsd-stable at 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:  dmitry at atlantis.dp.ua
nic-hdl: LYNX-RIPE