From owner-freebsd-ports@FreeBSD.ORG Sun Jul 29 04:13:02 2007 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A427516A420 for ; Sun, 29 Jul 2007 04:13:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 7DA7913C53C for ; Sun, 29 Jul 2007 04:12:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9279 invoked by uid 399); 29 Jul 2007 04:12:53 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 29 Jul 2007 04:12:53 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 28 Jul 2007 21:12:51 -0700 (PDT) From: Doug Barton To: Yoshihiro Ota In-Reply-To: <20070728210037.5ea54891.ota@j.email.ne.jp> Message-ID: <20070728210114.B16750@qbhto.arg> References: <20070726011654.cec378be.ota@j.email.ne.jp> <46A866BE.1000407@u.washington.edu> <20070726233610.e536c2e2.ota@j.email.ne.jp> <46A9A56E.5080608@FreeBSD.org> <20070727215923.a5c3c2aa.ota@j.email.ne.jp> <46AACAE3.2060401@FreeBSD.org> <20070728210037.5ea54891.ota@j.email.ne.jp> Organization: http://www.FreeBSD.org/ X-OpenPGP-Key-ID: 0xD5B2F0FB X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-ports@freebsd.org Subject: Re: Call for testers for yet another ports upgrade program, 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, 29 Jul 2007 04:13:02 -0000 On Sat, 28 Jul 2007, Yoshihiro Ota wrote: > On Fri, 27 Jul 2007 21:49:39 -0700 > Doug Barton wrote: > >> Hiro, >> >> I'm happy to respond to you, but first I'd like to make clear that I'm >> not trying to talk you out of anything. If there is a better way to >> manage ports, or even just a different approach, I'm all for it. I >> don't think portmaster is a "one size fits all" tool, and I'm not >> trying to make it one. > > Doug, > > The same goes here. Great! I'm glad we understand each other. :) > I see. When I just started ports+, I also attempted doing like that. > However, when I looked into bsd.port.mk, I found that the ports system > uses the INDEX file for pretty-print-run-depends-list. Then, I decided > to read the INDEX file myself for 1. it's faster to parse it myself, > 2. more information is available, and 3. prevent generating processes. That's a very reasonable conclusion. FWIW, the primary reason I chose to ignore the INDEX is all of the problem reports on the -ports list from portupgrade users about something breaking because of problematic INDEX generation. Being able to use 'make fetchindex' has solved a lot of those, but the other issues that arose as I studied further are the problems of dependencies changing based on what is installed already on a system, and what options the user chooses in the 'make config' stage. There is also of course the problem of the INDEX sometimes being just a little bit behind the ports tree. That's not a criticism, just a fact of how things work. Having the users generate their own INDEX solves some of these issues, but it introduces some new problems. The first is obviously the time it takes to generate (when you compare that to the time portmaster takes to recurse the dependencies itself I think portmaster comes out ahead), and the second is that the user has to maintain a full ports tree even if they will never use a lot of those ports. I know I have a pretty big refuse file for c[v]sup, and I was not interested in the additional bandwidth and storage that a full tree entails. >> The benefit comes when you actually start building stuff and because >> all the information about the up to date ports is cached, it won't >> have to be reevaluated. > > What do you mean by cached? Is it file-cache by VM? Is it something > the ports system do? Or is it something else? Portmaster starts a parent process to upgrade the port(s) specified on the command line. It then spawns children as needed to handle the upgrades of individual ports. Each child process inherits a set of variables that describe what is already known about the "up-to-date-ness" of the ports that have already been examined. The child adds whatever information it discovers and feeds that back to the parent. Lather rinse, repeat. hth, Doug -- This .signature sanitized for your protection