Re: [Bug-tar] Re: AMTAR brokenness

[Paul Eggert]

Alexandre Duret-Lutz <address@hidden> writes:

>  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.

OK, but hold on a second: what's the goal here?  If the goal is to
produce ustar format, then you're correct: we shouldn't try plain
"tar" (without checking it, anyway).  But if the goal is to produce
tarballs that work, then the most likely consumer of the tarball right
now is GNU tar 1.13.25 or earlier -- which chokes on some ustar
tarballs.

Given all the hassles that will accompany any change, perhaps we
should give the maintainer a more gradual upgrade path.

For example, we could add an automake macro AM_TAR_FORMAT.
AM_TAR_FORMAT([v7]) would use the current behavior (flawed as it is --
at least it's something people are familiar with).
AM_TAR_FORMAT([ustar]) would attempt to generate ustar format, using
the commands "tar --format=ustar", "tar" (if not GNU tar), "pax -x
ustar", and "cpio -H ustar", in that order.  Likewise for other
formats as we find the need to support them.  The default could be v7
for now, but we can warn people that it is subject to change: it could
change to ustar, then posix, for example.

That way, adventurous maintainers could use AM_TAR_FORMAT([ustar])
now, whereas more conservative types would avoid any change in
behavior.

> What about Ralph's `cpio -H ustar' suggestion?

I'd put cpio last on the list, with the lowest priority.  Traditional
UNIX cpio had serious bugs whenever two files had inode numbers that
were the same modulo 2**16.  This problem persisted for many years (up
until I stopped using cpio -- perhaps it still has the bug for all I
know).  GNU cpio cannot yet handle large files or archives (i.e.,
larger than 2 GiB on typical x86 hosts).