From owner-freebsd-ports@FreeBSD.ORG Sat Jul 21 10:32:56 2007 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0101616A419 for ; Sat, 21 Jul 2007 10:32:56 +0000 (UTC) (envelope-from michel@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9183713C45D for ; Sat, 21 Jul 2007 10:32:55 +0000 (UTC) (envelope-from michel@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id l6LAWsDe005077 for ; Sat, 21 Jul 2007 12:32:54 +0200 (CEST) X-Ids: 168 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id ECF462377BC for ; Sat, 21 Jul 2007 12:31:22 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id ECC8580; Sat, 21 Jul 2007 12:32:52 +0200 (CEST) Date: Sat, 21 Jul 2007 12:32:52 +0200 From: Michel Talon To: ports@FreeBSD.org Message-ID: <20070721103252.GA68570@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.168]); Sat, 21 Jul 2007 12:32:54 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.7/3713/Sat Jul 21 03:18:46 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-j-chkmail-Score: MSGID : 46A1E0D6.002 on shiva.jussieu.fr : j-chkmail score : X : 0/50 0 0.510 -> 1 X-Miltered: at shiva.jussieu.fr with ID 46A1E0D6.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: Subject: Re: Proposal for another category in INDEX: common_deps 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: Sat, 21 Jul 2007 10:32:56 -0000 Doug Barton wrote: > > and then mainly as a resource to make easier the lives of the > > people that write ports management software. > > Well, I'm one of those people, and portmaster ignores the index file > altogether, for whatever that's worth. Me too for pkgupgrade. In my case the rationale is that, if something has to be compiled on the machine, it is best that the information is exactly compatible with the state of the ports tree on the machine. So like portmaster, pkgupgrade recomputes the Index fields for all installed ports and their dependencies. This is no big deal, uses less than a minute on a modern machine, totally negligible compared to the time for downloading distfiles or packages, or running pkg_delete or pkg_add. In pkgupgrade case one needs to deal with both binary packages and ports, so RUN_DEPENDS is used to discover dependencies of packages, and all other fields coalesced to discover dependencies of ports. There is of course a further subtelty: you have to compare old and new ports which may have changed name in between. The rule i have taken is to systematically use the most recent name as it appears in the ports tree, and evolve old names following the MOVED file (perhaps recursively) to be able to compare them with new names. This leaves on the border of the road ports which have disappeared in between, but anyways you cannot upgrade them by source ... I think that portmaster does more or less the same, while, if i don't err, portupgrade doesn't and tries to guess new names using heuristics, which sometimes spectacularly fails. Well, all this to say that, for the purpose of upgrading a port, it is the coalesced values of fetch, extract, etc. which is of interest. Of course, for other purposes, like Mark Linimon says, these fields may have individual interest. -- Michel TALON