From owner-p4-projects@FreeBSD.ORG Wed Apr 14 15:18:58 2010 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C73611065677; Wed, 14 Apr 2010 15:18:58 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A79F106566C; Wed, 14 Apr 2010 15:18:58 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4688FC0A; Wed, 14 Apr 2010 15:18:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o3EFJ8J4045913; Wed, 14 Apr 2010 15:19:08 GMT (envelope-from kientzle@freebsd.org) Received: from horton.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id ueq3h9s2mnvdutqcg2dzmrgfh2; Wed, 14 Apr 2010 15:19:08 +0000 (UTC) (envelope-from kientzle@freebsd.org) Message-ID: <4BC5DCDD.2060902@freebsd.org> Date: Wed, 14 Apr 2010 08:18:53 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20100314 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Garrett Cooper References: <201004121230.o3CCUsIX029146@repoman.freebsd.org> <4BC3EB5B.5070801@freebsd.org> <4BC53714.80805@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Forsythe , Perforce Change Reviews , Florent Thoumie Subject: Re: PERFORCE change 176831 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 15:18:59 -0000 >>>> But I really do believe that single-pass direct >>>> install is feasible and is eventually where we want >>>> to be. The key insight for me was when Florent recently >>>> pointed out that you could just read the +CONTENTS, >>>> then do a verify pass, then extract everything. >>>> (Any conflict during the extraction pass >>>> would be a fatal error: delete everything >>>> extracted so far and scream loudly.) >>> Agreed on the final point. I'm kind of interested though about the >>> first point -- the verify pass -- are you verifying that the contents >>> are sane on the disk or in the tarball? If so, why not just verify the >>> contents after the fact... That is: * Read and parse +CONTENTS * Check the package database to verify that dependent packages exist and that no conflicting packages exist. If there's a problem, ask the user what to do. (This gets complicated.) * Check the disk to verify that none of the files listed in +CONTENTS already exist on disk. If so, there's a conflict and we must ask the user what to do (this gets complicated). * Extract all of the files, failing if there is a file in the tarball that wasn't listed in +CONTENTS or if there is a file in the tarball that already exists on disk (which must have been created in the intervening window).