Subject: Re: pkgdiff -- tools for easier pkgsrc patch creation and maintenance
To: Greg A. Woods <>
From: Thomas Klausner <>
List: tech-pkg
Date: 07/05/2000 12:35:14
Mutt made be believe that Greg A. Woods wrote:
> [ On Saturday, July 1, 2000 at 04:43:04 (+0200), Thomas Klausner wrote: ]
> > Subject: Re: pkgdiff -- tools for easier pkgsrc patch creation and maintenance
> >
> > pkgdiff in special is a shell script ;-)
> Well, I'm glad to hear it's not a perl script, but I'm still wondering
> why it's a separate script at all:
> I've had the following in my version of mk/ for some time
> now.  It could be converted to the "patch-aa" style of naming, but since
> I hate that style you won't convince me to do the conversion!  ;-)
> makepatch:

The work that that target does is done by mkpatches, which _is_ a Perl
script; one of the reasons for that is that the patch-aa-style is easy
to do in Perl ;-)

pkgdiff itself takes care of not allowing any RCS tags in the diffs,
(which this target doesn't); and patchdiff compares the new set of patches
with the old one, which I found easiest to do in Perl.

And mk/ alrady contains too much code ;-)

> Personally I'm still not even really that happy with having separate
> patch files.  I'm now convinced they should be mushed all into one and
> that separate files should only be used if an optional feature is added
> by patching (eg. instead of just turning on a config option) or of
> course if a patch is fetched from somewhere else.  This has the added
> advantage that one can easily manage original package sources by simply
> using the vendor-branch feature of CVS and then trivially create the
> patch file with one "cvs patch" command.

I'm not sure I understand what you gain from the
all-patches-in-one-file method, but I think splitting the patches into
many files has some advantages when you have to maintain the package,
especially when updating. And it probably also saves on sup transfer
costs if you only have to get changed files and not the whole big
patch every time one of the sub-patches changes.

If I understand you correctly: a script for splitting a patch
generated by 'cvs patch' into many files can't be hard to write.


Thomas Klausner -
I wanted to emulate some of my heroes, but I didn't know their
op-codes. --dowe