From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 02:29:09 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3F0316A400 for ; Sat, 12 May 2007 02:29:09 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.freebsd.org (Postfix) with ESMTP id AC08A13C43E for ; Sat, 12 May 2007 02:29:09 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from ip04.eastlink.ca ([24.222.10.20]) by mta02.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JHW0071CPKKGGP0@mta02.eastlink.ca> for freebsd-hackers@freebsd.org; Fri, 11 May 2007 23:29:08 -0300 (ADT) Received: from blk-224-199-230.eastlink.ca (HELO dwpc.dwlabs.ca) ([24.224.199.230]) by ip04.eastlink.ca with ESMTP; Fri, 11 May 2007 22:59:56 -0300 Received: from dwpc.dwlabs.ca (www.dwlabs.ca [192.168.0.10]) by dwpc.dwlabs.ca (8.13.8/8.13.8) with ESMTP id l4C2TOA7002423; Fri, 11 May 2007 23:29:30 -0300 (ADT envelope-from duane@dwpc.dwlabs.ca) Received: (from duane@localhost) by dwpc.dwlabs.ca (8.13.8/8.13.8/Submit) id l4C2TOrC002422; Fri, 11 May 2007 23:29:24 -0300 (ADT envelope-from duane) Date: Fri, 11 May 2007 23:29:24 -0300 From: Duane Whitty In-reply-to: <20070511212847.GA30211@xor.obsecurity.org> To: Kris Kennaway Message-id: <20070512022924.GA1017@dwpc.dwlabs.ca> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAzDREYY4MfmdGdsb2JhbACQAAE2 X-IronPort-AV: i="4.14,525,1170648000"; d="scan'208"; a="214492920:sNHT27859770" X-Virus-Scanned: ClamAV version 0.88.6, clamav-milter version 0.88.6 on dwpc.dwlabs.ca X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on dwpc.dwlabs.ca References: <200705112302.35380.dragonsa@highveldmail.co.za> <20070511212847.GA30211@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Cc: freebsd-hackers@freebsd.org Subject: Re: DPS Initial Ideas X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 02:29:10 -0000 On Friday, 11 May 2007 at 17:28:47 -0400, Kris Kennaway wrote: > On Fri, May 11, 2007 at 11:02:31PM +0200, David Naylor wrote: > > Hi, > > > > Thank you all for your responses, it has given me much to think about. I > > guess there is consenses that there is room for improvement in the current > > pkg system. Attached are some of my initial ideas about what is required and > > expected in any (and all future) package systems. > > > > Since I am going away this weekend I have had limited time to work on this > > document and as such it is in early stages of development. My objective is > > to get a clear understanding and target of what is required for this new > > package system. > > There are a couple of ground rules you need to appreciate: > > 1) Backwards-compatibility with the ports collection is absolutely > required. This may not be an issue for you, but some past proposals > have included the phrase "rewrite the ports collection to use tool X". > This is pretty clearly a non-starter, unless you also provide a > workable (i.e. mostly automated) migration strategy. > > 2) Integration with ongoing work is required. e.g. we have two people > working on extending the existing pkg_tools as part of the google > summer of code (including one who is working on integrating the > metadata into a berkeley DB database, to attempt to solve the > scalability problems we are starting to run into as the typical number > of installed packages on a user system grows), and we're not going to > throw away their work. > > 3) Dependencies on new code have a high bar for adoption. i.e. if you > propose to bring in new software packages into the base system, you > need to definitively prove that they are necessary for solving a > serious problem. > > 4) When people hear the phrase "new package system" they take this as > an invitation to pile on feature requests, pet peeves, etc that would > be "great to have" in a new package system. While it helps to be > aware of these ideas, and where appropriate to avoid designing a > system that prevents them from being added, the temptation is to > undergo feature creep: the proposal expands to engulf all possible > features and ends up collapsing under its own weight (also known as > "Second System Syndrome"). Stay focused on a core idea you want to > achieve, and you might avoid this problem which has killed the last N > serious "new package system" projects. > > I think your current proposal falls short on points 2) and 3). In > particular, I don't see where SQLite is necessary to solve any > problems we are currently facing, and your proposal conflicts with > existing work. > > Kris Kris, In your opinion what is the biggest problem(s) the ports system and the package building system currently face? Is this a common problem, i.e., is the issue facing building from ports the same as installing from pre-built packages? I ask this in the context of infrastructure as opposed to any tools currently being used. Is it hoped / planned that storing the metadata in a berkeley DB database will help with the parallelization of package building? If only one thing was going to be done to improve the ports system, not including drafting more volunteers :) , what would you recommend that one thing be? Duane