Subject: Re: pkg/10630: fvwm95 build stops at patch
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-pkg
Date: 07/20/2000 18:46:22
[ On Thursday, July 20, 2000 at 18:06:09 (-0300), David Maxwell wrote: ]
> Subject: Re: pkg/10630: fvwm95 build stops at patch
> On Thu, Jul 20, 2000 at 12:14:33PM -0400, Greg A. Woods wrote:
> > Yet another reason why package patches should always be automatically
> > generated and kept in *ONE* file.  :-)
> > 
> > This would definitely make it much harder for pkgsrc maintiners to make
> > mistakes like this.
> Not really, it's just as easy to miss a file being modified in a patch
> file when you're appending a new patch at the bottom, as it is to miss
> it in a different file.

Ah, but you should always rebuild the entire patch file, every time,
from scratch.  If you have one patch file containing all "pkgsrc"
patches for a package then you never manually or otherwise edit that
file -- you only ever re-create it from scratch every time.  This is
done either with a Makefile target like the "makepatches" target I
posted earlier, or with CVS (eg, with "cvs patch") if you use CVS to
assist in this job.

> Now that there's a good tool for building patch sets though, getting into
> a habit of using it to generate the whole patch directory would be good.

I find it hard not to use a tool that does all the work for me!

Of course anyone can argue that with a tool it's irrelevant whether or
not one builds one patch file or many patch files.  However such a
narrow view of the problem ignores all the other negative issues
surrounding the use of multiple patch files.

Also note that regardless of whether there's one patch file or many,
there still needs to be some mechanism that identifies which changes go
into the official patches, and which are maintained separately (the so
called "PATCHFILES" patches, such as are in www/squid).  With CVS this
kind of separation can be done with branches and merging.  With more
"manual" techniques this can be done by automatically reversing the
third-party patches before trying to re-create the official patches.  My
overly simple "makepatches" target doesn't deal with this issue (yet).

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>