Thanks for the reply.
The archive does appear to be using GNU format:
drw1@nasr:~/Documents/Software/Evaluation$ bsdtar tvvf SpiderOakONE-6.1.5-x86_64-1.tgz | tail -1
Archive Format: GNU tar format, Compression: gzip
tar-1.13 doesn't seem to report format explicitly:
drw1@nasr:~/Documents/Software/Evaluation$ tar-1.13 --help | tail
nil, existing numbered if numbered backups exist, simple otherwise
never, simple always make simple backups
GNU tar cannot read nor produce `--posix' archives. If POSIXLY_CORRECT
is set in the environment, GNU extensions are disallowed with `--posix'.
Support for POSIX is only partially implemented, don't count on it yet.
ARCHIVE may be FILE, HOST:FILE or USER@HOST:FILE; and FILE may be a file
or a device. *This* `tar' defaults to `-f- -b20'.
Report bugs to <firstname.lastname@example.org>.
But if I create a little test archive using 1.13, bsdtar reports back that it is GNU format.
In any case, I didn't create the package myself; SpiderOak lists packages for Slackware in their Download area
. And, indeed, installpkg reports that it is not created with makepkg, so it's likely they are tarred with a newer version of tar.
In fact, it appears to be a pretty nuanced thing. If I tar . with 1.29 and list with 1.13, all is well:
bash-4.3# tar-1.29 cf - . | tar-1.13 t | grep spideroak
But if I tar * with 1.29 and list with 1.13, the filename gets truncated:
bash-4.3# tar-1.29 cf - * | tar-1.13 t | grep spideroak
Using 1.13 -> 1.13 or 1.29 -> 1.29 works as expected, of course.
So, notwithstanding that the format of the tar archive is notionally the same (GNU), there seems to be some difference between 1.29 and 1.13.
If I untar their package (using tar-1.29) and run makepkg, all is well when I install.
Anyway, looks as though we can chalk this up to not using makepkg, but I wonder how often this happens given that Slackware packages use standard tar extensions, so non-Slacker third-parties wouldn't necessarily suspect that there was a tar-version-dependency.
Edit: I'll also alert the folks at SpiderOak that they ought to be building Slackware packages using pkgtools, and if they can't do that it's probably better to have Slackers use rpm2tgz or something.