Re: Systems with non-posix TAR implementations: How to handle
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
Show 12 quoted lines
>> 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.
Show 10 quoted lines
> 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