[ On Friday, October 6, 2000 at 02:57:54 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: pkgsrc reorg
>
> have you tried maintaining such a file? When you update a pkg to a new
> version, it's much easier, to apply one patch at a time and see if it
> fails is still needed or included in the new version. There's a reason we
> have the 'one file per patch' rule, and we're not going to sacrifice over
> some optimisation.

I think official NetBSD pkgsrc maintainers should really try to use CVS
to manage the changes to third party code that become pkgsrc patch
files.  Doing proper merges with CVS is far safer and cleaner than
manualy playing around with patch files.

Just import each package to a local repository.  Make your tweaks for
NetBSD and commit them.  Tag the result and create a diff with "cvs
rdiff" from the vendor branch and put that output in a single pkgsrc
patches file.  Next time you upgrade the package start by first
importing the new release to your local repository again.  Do a merge
and recompile and re-test.  Once all is well again just re-create that
patch file with "cvs rdiff" and update the pkg makefile, etc. as per
normal.  I've done this just fine by checking out my working directory
under pkgsrc/.../.../work/foo-X.Y to simulate the unpacked tar file and
thus I've been able to take advantage of the pkgsrc build infrastructure
directly for testing the entire build and install process prior to
creating the patch file.

Of course you don't have to use CVS -- it just makes the merging of new
vendor releases ever so much easier.  You can use any kind of source
code control tool that supports at least two SCCS/RCS style branches
(including the trunk) and can do the equivalent of tagging matching
revisions in each file.  You can also just use a virgin copy of the
original source tree and create the patch with "diff -ur" against the
hacked directory, but then you've got to make sure you remove all
product files, etc. -- with CVS you only ever diff against the imported
files, regardless of the state of product files in the working
directory.

The only tricky part is sometimes in making sure that you don't import
product files which will always be produced during the pkgsrc build but
which are sometimes also included in the original distribution.  However
it would be trivial to create a "cvs-ready" target in the pkgsrc make
rules such that a new release could be automatically unpacked and
tentatively cleaned up in preparation for an import (based on what had
to be done to the previous release to prepare it, eg. running something
like "./configure && make maintainer-clean").  A "cvs-import" target
could even be written that would by default do all the laborious tasks!

I've been doing similar things for well over 6 years now with CVS and I
can assure you that not only do the processes I describe work
exceptionally well, but they also eliminate many of the headaches one
can get from trying to manage third-party code without the help of
appropriate tools (something I also did for a similar amount of time
prior to the first usable release of CVS-II).

Since my concerns on these matters w.r.t. NetBSD sometimes seem to fall
on deaf ears I think it would also help a lot if occasionally official
NetBSD developers, pgksrc maintainers included, pretended to be ordinary
third-party developers like the rest of us and tested procedures such as
importing and tracking NetBSD source in a CVS vendor-branched repo.  By
three or four cycles I think you'd all be so firmly in favour of having
single patch files with static names that you'd never even be able to
dream of how you'd managed to work with the current mess, unless it was
in a nightmare!  :-)

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