[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'tar' in the GNU Coding Standards
From: |
Ralf Wildenhues |
Subject: |
Re: 'tar' in the GNU Coding Standards |
Date: |
Tue, 3 Nov 2009 07:20:21 +0100 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
* Dr. David Kirkby wrote on Sun, Nov 01, 2009 at 10:38:51PM CET:
>
> The best way IMHO would be for GNU tar to default to a more portable
> format rather than its own 'standard'.
I'm not sure whether that will happen: the more portable format has more
limitations, such as the 99 character path length limit.
> Reading http://www.gnu.org/software/automake/manual/tar/Formats.html
>
> it implies this will happen. The sooner the better I feel. I do not
> know how well Sun's tar will handle the tar format of GNU tar then.
I'm not sure what the text is meant to imply will happen, but I find it
weird if the GNU tar manual were to imply what direction GNU Automake
will evolve towards in the future.
> I know there is one package in the Sage project which will not
> extract with Sun's tar. But if one uses Sun's tar to create the
> tarball, GNU tar can extract it ok.
Well, can the tarball be created ok with the v7 format, and no symlinks?
> >The 'Releases' node of the GCS describes some of the precautions to use
> >when creating package tarballs. If possible, I think it would be
> >prudent to advise the tarball creator to use the most portable archive
> >format possible. The GNU tar manual has `Portability' and `Formats'
> >sections about this, and the GNU Automake manual node `Options' shows
> >how to apply them to your package, should you use automake. Automake
> >uses old v7 archive format by default for `make dist'.
>
> That sounds sensible. I'm not sure why GNU tar does not default to
> something sensible like that.
I'm afraid you'll have to ask on a tar mailing list, or read its manual
for a rationale.
> >>hence it's better the user was able to write:
> >>
> >>$ TAR=/usr/local/bin/gtar
> >>$ export TAR
> >
> >How would you set $(TAR) if not supplied by the user though?
>
> I'm not a wizard on Makefiles, but is it not possible to write them
> in such a way that if the environment variable 'TAR' is unset, then
> $TAR gets set to 'tar', otherwise it is whatever the TAR is set to?
Well. The make part of the answer is: Yes, with GNU make you can just
write
TAR ?= tar
and with portable make, we can of course still default TAR to tar in
configure.ac:
: ${TAR=tar}
AC_SUBST([TAR])
But that's not the real knack. If plain 'tar' is not sufficient, as you
imply, then the user must choose something different, or we need to have
a macro that automatically selects a better alternative. So, either we
need to amend installation instructions, which we're fairly reluctant to
do, or we need a good kind of test to distinguish good 'tar' from bad
'tar', which I wouldn't really know how to do well.
> Jöerg Schilling's 'star' is one other implementation I am aware of.
> He seems to have the knack of writing extremely portable code.
That's fairly irrelevant for the issue at hand though; the question is
not whether there exists a portable tar program (GNU tar would be a
candidate as well), but which kind of functionality you can expect to
be *already installed* on your users' systems.
> >BTW, I agree that egrep and fgrep should be fixed, as you noted
> >somewhere in this thread.
>
> Can you personally do something about the fgrep and egrep? Or do you
> know who to handle the issue to?
I'll handle it.
Thanks,
Ralf