Alexandre Duret-Lutz <[EMAIL PROTECTED]> 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).
