From owner-freebsd-ports@FreeBSD.ORG Sun Jul 29 01:00:46 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 4A7AE16A417; Sun, 29 Jul 2007 01:00:46 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id E5BA913C46C; Sun, 29 Jul 2007 01:00:45 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from dynabook-freebsd.advok.com (pool-141-151-95-122.phlapa.east.verizon.net [141.151.95.122]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 60514469A5; Sun, 29 Jul 2007 10:00:43 +0900 (JST) Date: Sat, 28 Jul 2007 21:00:37 -0400 From: Yoshihiro Ota To: Doug Barton Message-Id: <20070728210037.5ea54891.ota@j.email.ne.jp> In-Reply-To: <46AACAE3.2060401@FreeBSD.org> 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> X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 01:00:46 -0000 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. With my approach, if I can handle let's say 90% of cases, that's fair enough. But, let it do as FAST as possible. If one claims he has 32 CPU or 32 cores, let him use all. And let other tools like portupgrade and portmaster handle difficult cases. They are better for intarctive use. For instance, I can never do --recursive option in portupgrade in ports+. It is something impossible for a 'make' utiltiy to do. > Yoshihiro Ota wrote: > > On Fri, 27 Jul 2007 00:57:34 -0700 > > Doug Barton wrote: > > > >> Yoshihiro Ota wrote: > >> > > Could you tell me a bit more or point to a source if already > > written on how portmaster works. > > The man page has a good overview, I have documented it relatively > thoroughly, and I keep it up to date. You can either install the port, > or do: I will do so. > >>> However, "portmaster -a -n" wasn't not fast, neither. > > I should probably point out that this is the worst case scenario, > since by definition portmaster -a has to evaluate each installed port. > The vast majority of the time spent doing that though is in 'make -V > PORTVERSION'. 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. > 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? > I think it's useful and healthy to discuss where both the various > tools, and the infrastructure can be improved. Sure. I took what portupgrade is doing to upgrade ports to make ports+. I.e, saving dynamic libraries, and so on. When you mention something like 'make -V PORTVERSION', it gives a good idea how to get something out of the port system. It just occurred that as the ports system generates INDEX and ports+ uses it to write out Makefiles, the ports system might be able to write Makefiles for upgrading, too. Hiro