On Tue, May 07, 2002 at 05:14:42PM -0400, Greg A. Woods wrote:
> I just finally encountered a forced pkg_install upgrade on a system that
> doesn't have GNU Tar (and doesn't want it).  I was rather surprised and
> dismayed to find that pkg_create still requires GNU Tar.  I haven't been
> paying particular attention to changes in pkg_install, since I've been
> using my own version for a year now, but I though this issue would have
> been taken care of long ago.
> 
> Isn't "pax" the primary officially supported archiver on NetBSD?  It's
> in /bin ([g]tar isn't), after all, and it's been there for years.  The
> in-tree GNU Tar is also very OLD!  It's based on the 1.11.2 1993
> release, while 1.12 has been out since 1997!
> 
> A simple link to /bin/tar and /bin/cpio pretty much eliminates any need
> for GNU Tar entirely.  Although I'm not 100% certain I believe all the
> necessary fixes to make the pax front-end to 'tar' sufficiently
> compliant with GNU Tar have been available since 1999/10/22 (not long
> after 1.4.1 was tagged, IIUC), and one final desirable cleanup (-O) has
> been available since 2000/03/30.  All of these fixes have been in 1.5
> from the very beginning of its branch.  These fixes correspond with the
> fixes I made to my own copy of pax and I've used it successfully for
> nearly a year now with my own version of pkg_install.
> 
> I also submitted a PR last year (# 13699) including those fixes from my
> pkg_install so that it could use the 'tar' front-end to 'pax'
> exclusively.  The only reply to the pax-related portion of that PR was
> an informal question about testing (and the answer is easy enough to
> find with a trivial test of pax directly).
> 
> The only thing that makes this tricky in pkgsrc is that supported
> systems have a /usr/bin/tar which is GNU Tar.  My PR#13699 recommended
> instead that the /bin/tar link to /bin/pax be created.  This could be
> done by a new pkgsrc/pkgtools/pkg_install "INSTALL" script, but it would
> leave older systems with two slightly disparate "tar" commands.  I don't
> think this would be a "bad" thing, but it might confuse some folks.  The
> more certain fix though would be to modify pkg_create to use the 'pax'
> command-line directly instead of relying on the 'tar' front-end.  I'm
> considering updating my pkg_create patches to use the native pax
> interface, but I've not done that yet....
> 
> As for systems too old to have a modern enoung 'pax', well even a
> "DEPENDS" added to pkg_install right now to require a new & similar
> pkgsrc/pkgtools/pax module to upgrade ancient systems....

The issue with pax(1) is its support for the GNU tar -C extension.
Each package with a @cwd directive in its PLIST needs this to
function correctly. We are moving to eradicate these from pkgsrc,
but haven't finished the transition yet.

There are still 4 left, all in the japanese category.

Regards,
Alistair