Re: [Bug-tar] Re: AMTAR brokenness

[Alexandre Duret-Lutz]

>>> "Paul" == Paul Eggert <address@hidden> writes:

 Paul> Alexandre Duret-Lutz <address@hidden> writes:
 >> How about this scheme:

 Paul> In the light of later discussion, how about this scheme instead?

 Paul> Use the first of the following commands that works:

 Paul> tar --format=ustar
 Paul> tar
 Paul> pax -x ustar

This looks satisfactory when GNU tar 1.13.93 is installed, or
when GNU tar is not installed.  However, on most GNU/Linux
setups, which have GNU tar 1.13.25 installed, my understanding
is that will cause GNU-tarballs to be produced.

What if we try hard not to use such old GNU tar versions?

   Use `tar --format=ustar' if possible.
   If `tar' is GNU's:
      Use `pax -x ustar' if that works,
      or fall back to plain `tar'.
   Otherwise
      Use plain `tar',
      or fall back to `pax -x ustar'.

[...]

 Paul> The "tar" command has never been a POSIX requirement.  However, "pax"
 Paul> has never caught on, for various reasons, and it hasn't been
 Paul> road-tested as much as "tar" has.  It makes sense to use "pax" if
 Paul> "tar" is not available, but I wouldn't make "pax" my first choice.

I trust you.  However my impression from Sergey comments is that
older GNU tar versions should not be a choice at all when it
comes to creating ustar archives :(

What about Ralph's `cpio -H ustar' suggestion?  I've never used
cpio.  It looks like the -H option is non-standard, but is
supported by many implementations.  Probably this is even less
exercised than `pax -x ustar'.

 Paul> Many tar implementations have trouble with path names
 Paul> longer than 99 bytes.  This includes the current GNU tar
 Paul> official latest non-alpha release (which is buggy in this
 Paul> area).  It would be reasonable to add an automake option
 Paul> that checks for longer-than-99-byte file names, for
 Paul> people who are worried about such things.  

I agree.
-- 
Alexandre Duret-Lutz