From owner-freebsd-ports@FreeBSD.ORG Sun Jan 15 11:37:22 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 BFB0816A41F; Sun, 15 Jan 2006 11:37:22 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A2D343D45; Sun, 15 Jan 2006 11:37:20 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id k0FBbHAF083039; Sun, 15 Jan 2006 13:37:17 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.13.3/8.12.11) with ESMTP id k0FBc0JR082903; Sun, 15 Jan 2006 13:38:00 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43CA33E4.40809@ebs.gr> Date: Sun, 15 Jan 2006 13:37:08 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051223) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Barton 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> In-Reply-To: <43C97BEB.3030601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , 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: Sun, 15 Jan 2006 11:37:22 -0000 Doug Barton wrote: > Alexander Leidinger wrote: > >> On Sat, 14 Jan 2006 03:45:10 -0800 Doug Barton wrote: >> >>> This is done too now, although it turned out to be a lot harder than I >>> expected. It required redoing how some of the internal stuff worked, >>> but in the end it made the whole script better, so I'm glad I pursued >>> this. As an extra bonus you can now do 'portmaster -af' and it will >>> force an update of all ports on your system, starting with the leaves. >> >> >> "Leafes" as in "those ports which no other ports depends upon"? > > > Yes. > >> If yes: are you sure this is a good idea? Wouldn't you think a better >> approach would be to start with those ports, which depend upon no other >> port (= "root" ports in my terminology)? > > > Yes, except that I left out one important part of that explanation. :) > > What portmaster does when asked to update a given port is (leaving out > some steps): > > 1. cd to the port directory > 2. make config > 3. Get a list of dependencies by doing 'make all-depends-list' > 4. Recursively check to see if each of those dependencies is up to date, > and update it if not by launching a child process of itself > 5. Return to the original port, and update it > > So, in the non-forced update case, any dependencies of a leaf port will > get updated before the leaf does. Anything that is already up to date > won't get touched. In the forced update case, we'll recurse through the > dependency list of the first leaf port all the way down to the root > ports, then back up through each dependency, and finally back up to the > leaf. In the force case, I keep a list of ports that have been updated > so that we only have to do that once for each port. > > Now theoretically there is nothing wrong with your suggestion, and other > than the fact that I wanted to keep the same process in place for > updating all the ports as I do for updating them one at a time, I could > have done it that way. In fact, the more I think about it the more I > think it makes sense to do it in this order for the 'update all' case: > > 1. ports that have no dependencies (roots) > 2. ports that have dependencies, and are depended on (branches?) > 3. ports that have dependencies, and are not depended on (leaves) > > I'll do some testing on this and let you know, thanks for this suggestion. Can portmaster be used to do something like 'portupgrade -rf gnutls' (i.e. rebuild all dependent applications), like it is often requested in UPDATING? Cheers, Panagiotis