From owner-freebsd-ports@FreeBSD.ORG Wed Dec 3 02:24:46 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D17106564A for ; Wed, 3 Dec 2008 02:24:46 +0000 (UTC) (envelope-from fbsd06+4I=f88667b1@mlists.homeunix.com) Received: from fallback-in1.mxes.net (fallback-out1.mxes.net [216.86.168.190]) by mx1.freebsd.org (Postfix) with ESMTP id 01C298FC1B for ; Wed, 3 Dec 2008 02:24:45 +0000 (UTC) (envelope-from fbsd06+4I=f88667b1@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by fallback-in1.mxes.net (Postfix) with ESMTP id 65B36164702 for ; Tue, 2 Dec 2008 21:09:01 -0500 (EST) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9119B23E3FE for ; Tue, 2 Dec 2008 21:08:59 -0500 (EST) Date: Wed, 3 Dec 2008 02:08:57 +0000 From: RW To: freebsd-ports@freebsd.org Message-ID: <20081203020857.523645bc@gumby.homeunix.com> In-Reply-To: <20081202180743.GB70240@hades.panopticon> References: <20081202180743.GB70240@hades.panopticon> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Proposal: mechanism for local patches 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, 03 Dec 2008 02:24:46 -0000 On Tue, 2 Dec 2008 21:07:43 +0300 Dmitry Marakasov wrote: > I am not aware of any mechanism for this. But I agree that it's > really needed. Before (in cvsup times) we could just place patches > under files/ and be happy, but now when more people use portsnap > we need something better. I wonder if portsnap actually needs to behave the way it does. Portsnap stores its compressed snapshot as one .gz file for each port plus one for each additional file (files in Mk/ etc). When you do an "update" any modified snapshot files are extracted over the appropriate location in the ports tree. The reason that "portsnap extract" deletes patch-files is that before each .gz file is extracted, the corresponding file or port directory is deleted. I wonder why, if an "update" can decompress over the top of a port, an "extract" need to delete it first. I can't think of any good reason offhand. Modifying portsnap not to delete extra files is just a matter of deleting one line. The behaviour of portsnap extract would then be virtually identical to csup. Alternately, it wouldn't be much harder to create a new portsnap command.