increasingly packages need gtar or pax-with-libarchive

[Greg Troxel <gdt%lexort.com@localhost>]

On netbsd-8, I had a failure to build
textproc/py-sphinxcontrib-serializinghtml because /bin/tar (pax-as-tar)
unpacked the tarball incorrectly (avoiding pedantry and discussing what
the standards are, at least not how the people that created the tarball
intended).

Unpacking throws lots of

tar: File extended headers posix ustar archive. Extracting as plain files. Following files might be in the wrong directory or have wrong attributes.
----------  1 root     wheel         27 Dec 31  1969 ././@PaxHeader
drwxr-xr-x  2 502      staff          0 Dec 31  1969 sphinxcontrib-serializinghtml-1.1.4/sphinxcontrib/serializinghtml/locales/zh_TW
tar: File extended headers posix ustar archive. Extracting as plain files. Following files might be in the wrong directory or have wrong attributes.
----------  1 root     wheel         28 Dec 31  1969 ././@PaxHeader
drwxr-xr-x  2 502      staff          0 Dec 31  1969 sphinxcontrib-serializinghtml-1.1.4/sphinxcontrib/serializinghtml/locales/zh_TW/LC_MESSAGES
tar: File extended headers posix ustar archive. Extracting as plain files. Following files might be in the wrong directory or have wrong attributes.
----------  1 root     wheel        156 Dec 31  1969 ././@PaxHeader
-rw-r--r--  1 502      staff        755 Dec 31  1969 sphinxcontrib-serializinghtml-1.1.4/sphinxcontrib/serializinghtml/locales/zh_TW/LC_MESSAGES/sphinxco
tar: File extended headers posix ustar archive. Extracting as plain files. Following files might be in the wrong directory or have wrong attributes.
----------  1 root     wheel        156 Dec 31  1969 ././@PaxHeader
-rw-r--r--  1 502      staff       1007 Dec 31  1969 sphinxcontrib-serializinghtml-1.1.4/sphinxcontrib/serializinghtml/locales/zh_TW/LC_MESSAGES/sphinxco

and there is indeed a "sphinxco" file when unpacked.  There are similar
problems with a few other sphinxcontrib-foo packages, and surely they
are the same thing.

Using gtar to extract results in an OK build.
Using nbtar, bsdtar, pax all fail.

It seems clear that this distfile is using some new pax feature that is
supported with
  GNU tar
  NetBSD libarchive tar (>=9)
and not supported with
  NetBSD pax tar (<=8)
  NetBSD pax (<=8 at least)

This is particularly bad because nbtar fails to extract correctly
without erroring out, and the build proceeeds

So, options seem to be:

1) Add EXTRACT_USING=gtar to such packages (unconditionally).

2) Add EXTRACT_USING=gtar on NetBSD <= 8 to such packages.

3) Add some variable e.g. SHINY_PAX_FORMAT that if set, forces gtar if
default tar isn't good enough.

4) Add a check for unpacking errors and fail the build if so.

5) Set NetBSD <= 8 to gtar by default

Option 1 isn't ok (drags in gtar on >=9).

Option 2 is sort of workable, but I think this situation is going to get
worse.

Option 3 is like 2 in terms of finding and fixing, but without as much
cut-n-paste.

Option 4 seems nontrivial, but a good thing if we don't do 5.

Option 5 seems reasonable, except that people that compile very few
things will have gtar when they might not had it installed otherwise.  I
wonder how many people that really is, and how much pain the extra gtar
is for them, compared to the lossage and time to fix packages that are
incompatible with pax-as-tar.  gtar-base is only 2.7 MB.

In favor of option 5 is that we won't have mysterious packaging
failures, and we won't need to do per-package maintenance on upgrades.

In favor of option 2 would be a theory that these sphinx packages are
strange, and that these incompatible headers are quite rare.

So I lean to option 5, but if people thing the number of affected
packages is tiny, 2 would seem ok.