Subject: Re: making pkgsrc patch sets
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <woods@most.weird.com>
List: tech-pkg
Date: 06/24/1998 03:37:21
[[ moving to new tech-pkg mailing list.... ]]
[ On Tue, June 23, 1998 at 06:43:31 (-0700), Tim Rightnour wrote: ]
> Subject: Re: making pkgsrc patch sets (was: pkg/5617: Apache-1.3.0 packag
>
> I would take up arms against that.
>
> #1 head -2 patches/* tells me what files we are fiddling with
so does the following even more accurate and complete search:
grep '^--- .* ' patches/p*
> #2 Bob modifies his code, and integrates a fix we had in one of our patches,
> releasing version x+.01 Now I just go and delete patch-ab (or wotever) and
> things magicly work. No ripping the patch apart with vi, or patching and
> depatching to try and build a new one.. just one simple "rm"
That's not a very good way to manage patches. It's downright evil
actually (not to mention extremely error prone).
CVS, or something like it, which can generate truely accurate and
repeatable patches on demand is far safer and superior. Patches should
never be edited -- they should only ever be generated. Trying to
generate patches without a tool like CVS is very very very error prone
too.
CVS of course has the added advantage that it was designed with a fairly
elegant feature that specifically assists a code maintainer with
tracking local changes against "vendor" changes for code obtained from a
third party.
> #3 If I want to change the way we fiddle with file.c I just find the
> appropriate patch, and replace it. I dont have to recompile the whole big
> patch file, or do surgery on it.
"one change per patch file" does *not* imply "one file changed per patch
file"
CVS (or something like it) could be used to keep track of individual
change sets, but it soon becomes tedious, error prone, and unexpected
dependencies can creep in very easily.
Since the changes included as patches in a "package" module are always
applied in their entirety, and since they are in effect mandatory, I ask
again why are they not treated as a single consistent unit?
The *only* reason I can see to have separate patch files is when
separate patches may be necessary depending on the target platform.
Unfortunately this concept is not really possible to implement with the
current package Makefile system, and indeed is not likely necessary,
esp. for packages that come as source code (which of course is
realistically the only place patch files are useful anyway).
--
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>