From owner-freebsd-ports@FreeBSD.ORG Wed May 30 21:22:57 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E74C516A46C; Wed, 30 May 2007 21:22:57 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id CBE7613C489; Wed, 30 May 2007 21:22:57 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 486EF5B49; Wed, 30 May 2007 13:56:08 -0700 (PDT) To: Peter Jeremy In-reply-to: Your message of "Tue, 29 May 2007 18:04:55 +1000." <20070529080455.GM1161@turion.vk2pj.dyndns.org> Date: Wed, 30 May 2007 13:56:08 -0700 From: Bakul Shah Message-Id: <20070530205608.486EF5B49@mail.bitblocks.com> Cc: ports@freebsd.org, hackers@freebsd.org Subject: Re: Looking for speed increases in "make index" and pkg_version for 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: Wed, 30 May 2007 21:22:58 -0000 Peter Jeremy wrote: > On 2007-May-27 16:12:54 -0700, Bakul Shah wrote: > >Given the size and complexity of the port system I have long > >felt that rather than do everything via more and more complex > >Mk/*.mk what is is needed is a ports server and a thin CLI > >frontend to it. > > I don't believe this is practical. Both package names and > port dependencies depend on the options that are selected as > well as what other ports are already installed. A centralised > ports server is not going to have access to this information. I didn't mean a centralized server at freebsd.org but on your freebsd system and can know about what ports are installed. Conditional dependencies have to be dealt with. Perhaps the underlying reason for changing package names can be handled in a different way. What happens now is that mostly static information from various files is recomputed many times. While that can be handled by a local database, it seems to be a daemon provides a lot of benefits. Come to think of it, even a centralized server can work as there are a finite number of combinations and it can cache the ones in use. But all this is just an educated guess.