From owner-freebsd-www@FreeBSD.ORG  Thu Mar 11 15:16:57 2004
Return-Path: <owner-freebsd-www@FreeBSD.ORG>
Delivered-To: freebsd-www@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8F43A16A4CE; Thu, 11 Mar 2004 15:16:57 -0800 (PST)
Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 692D743D1F; Thu, 11 Mar 2004 15:16:57 -0800 (PST)
	(envelope-from linimon@lonesome.com)
Received: by mail.soaustin.net (Postfix, from userid 502)
	id 0823F14725; Thu, 11 Mar 2004 17:16:55 -0600 (CST)
Date: Thu, 11 Mar 2004 17:16:55 -0600 (CST)
From: Mark Linimon <linimon@lonesome.com>
X-X-Sender: linimon@pancho
To: "Simon L. Nielsen" <simon@FreeBSD.org>
In-Reply-To: <20040311230805.GC825@zaphod.nitro.dk>
Message-ID: <Pine.LNX.4.44.0403111712010.930-100000@pancho>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: freebsd-www@freebsd.org
cc: Alexey Zelkin <phantom@FreeBSD.org.ua>
cc: dan@langille.org
Subject: Re: www/64120: /mnt/www/en/ports/needs to be re-run
X-BeenThere: freebsd-www@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: FreeBSD Project Webmasters <freebsd-www.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-www>,
	<mailto:freebsd-www-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-www>
List-Post: <mailto:freebsd-www@freebsd.org>
List-Help: <mailto:freebsd-www-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-www>,
	<mailto:freebsd-www-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2004 23:16:57 -0000

> The idea I have been thinking about was e.g. using the INDEX file
> already generated elsewhere (e.g. the INDEX tinderbox kris already runs)
> for the build on www.  But it was just an idea, and I have no plans to
> work on that at the moment.  Also I haven't looked more closely into the
> consequences of doing this (with regards to mirrors).

As a suggestion, the Ports Monitoring database already has its own
internal representation of much of the metadata, with the exception
of the dependencies.  It has the advantage of being no more than one
hour out of date -- it knows to incrementally update individual ports'
metadata based on the output of a ports cvsup.  Pieces of it could
be recycled to do this kind of function, or it could create a report
that could be grabbed.

No doubt, this could also be done based off of FreshPorts' database,
which probably has a nearly identical set of metadata.

mcl