From owner-freebsd-ports@FreeBSD.ORG Tue Jan 17 03:28:29 2006 Return-Path: X-Original-To: freebsd-ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E27A16A41F for ; Tue, 17 Jan 2006 03:28:29 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A64143D4C for ; Tue, 17 Jan 2006 03:28:28 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 33758 invoked by uid 399); 17 Jan 2006 03:28:27 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Jan 2006 03:28:27 -0000 Message-ID: <43CC6459.1030506@FreeBSD.org> Date: Mon, 16 Jan 2006 19:28:25 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Alexander Leidinger References: <43BCF31F.8050900@FreeBSD.org> <1136501778.40648.17.camel@localhost> <43C38A38.1020408@FreeBSD.org> <1136893017.2410.9.camel@pav.hide.vol.cz> <43C8E446.5010603@FreeBSD.org> <20060114144016.1dc9fdd0@Magellan.Leidinger.net> <43C97BEB.3030601@FreeBSD.org> <43C99C50.6060608@FreeBSD.org> <20060115100936.zqxdnz9a1w0g4g4g@netchild.homeip.net> In-Reply-To: <20060115100936.zqxdnz9a1w0g4g4g@netchild.homeip.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pav@FreeBSD.org, freebsd ports Subject: Re: New /bin/sh based script to manage ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2006 03:28:29 -0000 Alexander Leidinger wrote: > Doug Barton wrote: > >> BTW, where the typical case of updating or installing a single port is >> concerned, going from the top down is the right thing to do, since >> dependencies will vary depending on OPTIONS chosen. However, for the >> case of updating all the ports that are already installed, your >> suggestion is a welcome optimization. > > After your explanation how portmaster operates I don't see the immediate > benefit for the entire update procedure. You just change the order in which > the ports are updated while still being consistent regarding the > dependencies. The main benefit is less nesting of portmaster processes, which I found in testing occasionally caused problems with dialog's interaction with OPTIONS. Other than that, you are probably right, "optimization" is not the right word. However, I do not think that the added complexity is an overwhelming burden, and I may end up reusing the code if I decide to try "no longer necessary ports" detection. I can also see potential situations where doing it in this order is a benefit to the user, particularly where a root, trunk, or branch port update fails, an attempt to update something higher up the tree can be delayed until it has a chance to succeed. At the end of the day, I'm not sure it makes a LOT of difference one way or the other, but I like the new code, so I'm going to keep it. :) Doug -- This .signature sanitized for your protection