Re: Systems with non-posix TAR implementations: How to handle

[Tor Arntsen <tor@spacetec.no>]

On Mon, Apr 26, 2010 at 19:50, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Am 26.04.2010 17:55, schrieb Tor Arntsen:
[..]
>> *** t0024-crlf-archive.sh ***
>> *   ok 1: setup
>> * FAIL 2: tar archive
[..]
>> The problem with that test is that the Tru64 V5.1 'tar' says 'This
>> doesn't look like a tar archive' on the generated file. However, it
>> turns out that the tar file generated by 'git archive --format=tar' is
>> fine, it's just that it's a POSIX tar archive and the Tru64 'tar'
>> program isn't POSIX tar format compatible.
>> How should we handle this? Just ignore errors in this test on Tru64,
>> or is there some other way that I missed?
>
> That depends: if you just want to make sure that the test works fine,
> you could install GNU tar, perhaps as gtar, and let TAR in Makefile (or
> config.mak) point to it.  If the test fails with a tar that understands
> the format then you've found a bug.

Done. Everything's fine with gtar. As far as the OSF1 'make test' is
concerned I've re-run it with gtar, native compiler and
SHELL_PATH=<self-compiled-bash>, and everything looks fine except some
UTF8 conversion tests which may be caused by some iconv lib issues on
this platform.

> It could get a bit more complicated if you want to use git archive to
> create tar files that the native tar can understand.  For most repos it
> should be sufficient to specify a tree instead of a commit, e.g. with an
> added colon:
>
>        git archive -o archive-without-comment.tar HEAD:
>
> This makes git archive leave out the comment entry, which might upset
> some tar implementations.  I don't know if that's sufficient to make
> Tru64 tar happy, though.

It indeed is happy with that, this will be very useful to know when
working on OSF1 and only having the native tar application.

Thanks,
-Tor