From owner-freebsd-stable@FreeBSD.ORG Sun Aug 27 17:34:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1904416A4DE; Sun, 27 Aug 2006 17:34:07 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F0B543D78; Sun, 27 Aug 2006 17:33:39 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k7RHH4et040129; Sun, 27 Aug 2006 20:17:12 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k7RHH4ps040126; Sun, 27 Aug 2006 20:17:04 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sun, 27 Aug 2006 20:17:04 +0300 (EEST) From: Dmitry Pryanishnikov To: Doug Barton In-Reply-To: <44F130B2.8010702@FreeBSD.org> Message-ID: <20060827193347.J1751@atlantis.atlantis.dp.ua> References: <5B7BD83A-6316-4C20-903E-B5D66D4F2642@khera.org> <44EB5354.6070007@paladin.bulgarpress.com> <44EB6411.4040406@paladin.bulgarpress.com> <20060823193309.GA77890@rambler-co.ru> <44ECBFE8.7000809@FreeBSD.org> <20060824082012.GA81296@rambler-co.ru> <20060827002203.A39026@atlantis.atlantis.dp.ua> <44F130B2.8010702@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: 5.5 to 6.1 upgrade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2006 17:34:07 -0000 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@freebsd.org Wed Aug 23 23:56:09 2006 Date: Wed, 23 Aug 2006 13:51:52 -0700 From: Doug Barton To: Ruslan Ermilov Cc: Vivek Khera , "Todorov @ Paladin" , freebsd-stable 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@atlantis.dp.ua nic-hdl: LYNX-RIPE