[ On Wednesday, July 5, 2000 at 12:35:14 (+0200), Thomas Klausner wrote: ]
> Subject: Re: pkgdiff -- tools for easier pkgsrc patch creation and maintenance
>
> 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 ;-)

but given that the -aa stuff is just as meaningless as -001, if not more
so, why bother?  ;-)

doing the -aa stuff without perl isn't very hard to do, btw, and if you
really have to you can use awk to do the conversions.

I wanted my quick hack to run really fast so I didn't want to do
anything I couldn't do with really small tools and really simple
algorithms.  Ideally I would have used shell arithmetic expansion but I
was sort of thinking that maybe bsd.pkg.mk should be semi-portable to
older non-POSIX shells that don't have arithmetic expansion support.

> 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.

Hmmm... RCS Ids.... yeah, well I'm not so enamoured with having RCS Ids
in my patch files in the first place -- I'd rather eliminate that
practice than jump through hoops to perpetuate it, and in my case I
wasn't doing this for the official TNF repository anyway!  ;-)

> And mk/bsd.pkg.mk alrady contains too much code ;-)

Yeah, well my script is only a very few more lines!  ;-)
(though it would be somewhat bigger if it preserved RCS Ids and avoided
touching files that hadn't changed since the last time...)

> 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.

Having maintained a bunch of my own pkgsrc-like packages, as well as a
bunch of local changes to NetBSD pkgsrc packages, I can assure you that
there are several reasons why having only one patch file is
advantageous:

1. if you use CVS to actually track the package patches then having only
   one file is a definite win in terms of ease-of-use.

2. if you do not use CVS it is easier to regenerate all the patches
   every time than it is to figure out which diff goes in which patch
   file (unless you use an automated script like your yucky perl one or
   my simple shell one in which case it doesn't matter so much! ;-)

3. having only one patch file means that little patches don't come and
   go on a regular basis which means fewer "cvs add" and "cvs remove"
   commands for everyone (and especially for those of us using CVS to
   track pkgsrc itself locally).

4. having fewer total files in pkgsrc is a very good thing to work
   towards!

5. if you do use a script to generate the patch it's a bit easier to
   arrange things in such a way that you don't disturb the existing
   patch file when no new changes have been made to the package, thus
   vastly simplifying, or rather eliminating, the RCS Id preservation
   requirement

6. did I mention yet that having fewer files in pkgsrc is a good thing?

In fact I still only think of just one reason why it's easier to manage
a whole bunch of files:  generating the diff and putting it into a
merged file by hand is "harder" than figuring out which individual patch
file to replace.  However if you use a script or CVS to regen all
patches then this argument disappears into the mist....

>  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.

That could be true though I'm not sure where the tradeoffs are between
having to keep track of all the files and actually transferring a bit
more content.

For rsync (and CVSup and CVS and FTP) it's definitely better to have
fewer files, even at the expense of some of them being larger.

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

That's very true, but I was trying to hide that fact!  ;-)

-- 
							Greg A. Woods

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