Proposal: mechanism for local patches

Adam McDougall mcdouga9 at egr.msu.edu
Wed Dec 3 10:01:24 PST 2008


RW wrote:
> On Tue, 2 Dec 2008 21:07:43 +0300
> Dmitry Marakasov <amdmi3 at amdmi3.ru> 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.


More information about the freebsd-ports mailing list