[ On Sun, June 21, 1998 at 06:35:27 (-0700), Tim Rightnour wrote: ]
> Subject: RE: pkg/5617: Apache-1.3.0 package OS configuration not quite ri
>
> On 20-Jun-98 Greg A. Woods spoke unto us all:
> # What I was talking about was creating the patches in the first place.
> # There are no tools in existance that create patch sets that follow the
> # guidelines (i.e. one "change" per file, etc.).  This could be done with
> # CVS, but it would still be *VERY* tedious.  Actually using CVS to try
> # and manage a pkgsrc module isn't much gain at all.
> 
> This is wholly off topic.. but since you brought it up.. (and because it may
> benefit others attempting to do this)

I'll try moving this to tech-ports (i.e. everyone please note the Reply-To!).

> I use a collection of scripts I wrote to do this:  very simple quick hacks.
> 
> Two are available at my web page www.futureone.com/~garbled
> One breaks a massive diff into lots of little diffs (useful for fixing freebsd
> style diffs)

This I don't do very often....  I'm either creating a brand new package
without looking at prior efforts (still something I do only rarely), or
trying to modify or fix an existing package (also quite rare), or most
commonly trying to upgrade a package to a newer version of the original
source.

> The other one quickly replaces ifdef __FreeBSD__ with both freebsd and netbsd
> defs. It is meant to be run on patches.

(Often another *perfect* use for "#ifdef unix"!!!!!! [unless it's a
4.4BSD specific feature].)

> This quick script, creates diffs by searching the tree for .orig files.  I use
> it with an alias called orig, which creates an original and loads the .c file
> into an editor.

This isn't necessary if you use CVS (esp. with the vendor branch
support) to manage the changes to the original package.  CVS makes this
part of the task entirely trivial.

Regardless of how you generate patches for the package though you'll end
up either breaking them into one per file, or mashing them all into one
patch file.  Multiple patch files introduce the need for strict order of
generation and application.

Strictly speaking I disagree quite strongly with the suggestion of
breaking patches up into one "change" per file.  This is a suitable
approach only for providing elective fixes.  When providing a change set
that's self consistent and entirely mandatory then it is much safer to
generate and use it as one single patch file.

> Again.. very simplistic.. but they save me hours of work.
> 
> #!/usr/pkg/bin/perl
> 
> if ($ARGV[0]) {
>         $begin = $ARGV[0];
> } else {
>         $begin = "aa";
> }
> $new = 0;
> 
> @files = `find . -name \\\*.orig -print`;
> 
> foreach $orig (@files) {
>   chomp($orig);
>   $orig =~ s+^\./++;
>   $new = $orig;
>   $new =~ s/.orig//;
>   system("diff -U 1 $orig $new >../patch-$begin");
>   $begin++;
> }
> 
> 
> ---
> Tim Rightnour    -  root@garbled.net
> http://www.zynetwc.com/~garbled/garbled.html

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>