From owner-freebsd-ports@FreeBSD.ORG Wed Dec 3 18:01:24 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 6081E1065675 for ; Wed, 3 Dec 2008 18:01:24 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 3237C8FC14 for ; Wed, 3 Dec 2008 18:01:23 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id C6ED471EF33 for ; Wed, 3 Dec 2008 12:44:07 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlmOU+pCTngx for ; Wed, 3 Dec 2008 12:44:07 -0500 (EST) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id A504771EF25 for ; Wed, 3 Dec 2008 12:44:07 -0500 (EST) Message-ID: <4936C567.70709@egr.msu.edu> Date: Wed, 03 Dec 2008 12:44:07 -0500 From: Adam McDougall User-Agent: Thunderbird 2.0.0.17 (X11/20080926) MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <20081202180743.GB70240@hades.panopticon> <20081203020857.523645bc@gumby.homeunix.com> In-Reply-To: <20081203020857.523645bc@gumby.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 18:01:24 -0000 RW wrote: > 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. > > I've encountered a similar situation where I wanted to add patches or even patch/replace standard files in a port to meet my needs, but portsnap wipes them out. For now I'm using cfengine to re-apply my local changes to the ports tree on about 10 systems, but I have to remember to run cfagent after portsnap manually (I don't want to use cfengine in daemon mode). I thought it would be nice if portsnap.conf would let me specify a post-execution command so I could make it run cfagent on its own, so there is little chance to forget. My goal is to allow customizations while retaining the same standard command procedures that would be used on a plain system, to provide consistency across the board without introducing custom scripts that replace standard commands. In that light, it would be useful if csup had something similar, however I practically never need to maintain patches to /usr/src/. Just posting this as food for thought.