AHA! This probably solves my unanswered question as to why cdrecord
doesn't compile on my system any more!

allison:/usr/pkgsrc/sysutils/cdrecord % make
=> Checksum OK for cdrtools-1.10.tar.gz.
===> Extracting for cdrecord-1.10
===> Required installed package gmake>=3.78: gmake-3.80 found
tar: Ignoring link containing `..' (../lib/getfp.c)
tar: Ignoring link containing `..' (../cdrecord/scsi_cdr.c)

etc

OK, what's the workaround?

On Wed, 23 Oct 2002, Frederick Bruckman wrote:

> On Wed, 23 Oct 2002, Jason R Thorpe wrote:
>
> > On Wed, Oct 23, 2002 at 09:25:03AM -0500, Frederick Bruckman wrote:
> >
> >  > This "pax" bug^H^H^Hfeature also breaks binary packages (PR bin/18759).
> >  > It needs to be fixed in "pax".
> >
> > I seem to recall that this is what the GNU tar security issue was all
> > about...
>
> I see. So I guess the battle's already over, so "pkgsrc/mk" needs to
> use "pax --insecure" everywhere that "tar" was used, and "pkg_create"
> and "pkg_add" need to implement the old "tar" format in C?
>
> For what it's worth, old NetBSD 1.6 "pax" has an interesting "forward
> compatibility" twist, when used to create archives, in that it sees
> "--insecure" as a non-existent filename and only warns (by virtue of
> not understanding long options), rather than balking as it would with
> a non-supported short option, but that doesn't help at all for
> extracting archives.
>
> Frederick
>

-- 
Hisashi T Fujinaka - htodd@twofifty.com
BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte