[ On Saturday, September 22, 2001 at 12:38:21 (+0200), Tomasz Luchowski wrote: ]
> Subject: Re: pkg/14037: Update sysutils/xnc to 4.4.6
>
> Please, please modify your pkgsrc/category/package/* and send output
> of "cvs diff" next time! It's way easier to look at the changes and
> apply them; fetching tarball and comparing with pkgsrc version is very
> unhandy - one has to edit CVS/Root to be able to check this in.

I personally find diffs to pkgsrc modules to be nearly incomprehensible
sometimes, especially when they involve patches to patches.

In the end though the only really important difference between unpacking
a new version of a pkgsrc module and applying patches is that patches
have a better chance of easily removing out-dated files whereas few
archivers are trusted to remove files, or even have a way for the
submitter to specify that some file should be removed (which of course
is a _good_ thing!  ;-).

When I'm upgrading a pkgsrc module from someone's submitted module (not
very often these days as the maintainers are generally faster at this
than I am and I can just "cvs update") I generally first unpack it into
a new directory aside the existing one so that I can do "diff -rq old
new" to see if any files were removed, and then unpack it again over top
the existing directory and manually remove (or at least tag as removed)
any removed files.

All the other issues are handled (eg. lost changes in the master version
caused by the submitter not having an up-to-date copy are visible
because "cvs diff" will show a decremented $NetBSD ID line), and of
course you can instantly see the diffs

> tech-pkg is on the CC, because you're not the only one who likes
> to tarup package updates.

In all cases I really really really dislike any non-ascii "packaging" of
pkgsrc modules.  I want to be able to read the whole thing, in ascii, in
the e-mail or in the PR in GNATS.  It's bad enough to have to go to some
far away site to get the archive (esp. when you're not online!), but
even worse a uuencode'd or base64 MIME'd blob in the PR only wastes
space for no good reason.

There is a very widely known, widely used, and widely accepted group of
tools that can package up the kinds of files found in pkgsrc modules so
that they can be safely transmitted though Usenet (and thus can be
safely transmitted via e-mail and send-pr and can be safely stored
without risk of corruption in GNATS).  The most common of these is
called "shar" (and its grandparent is "bundle").  There's a copy of
"shar" in /usr/bin on every NetBSD system.  There are probably dozens of
other variants of each as well, and of course there's at least one such
in pkgsrc:  archivers/gsharutils.

Ideally pkgsrc modules should be shar'ed with their directories so that
they can be unpacked in an empty directory.  This usually works right,
(but only if you "make clean" first :-):

	shar * */*

Note that gsharutils contains 'gunshar' -- a slightly safer way to
unpack random shars without risking that they contain arbitrary shell
code.

-- 
							Greg A. Woods

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