[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
  TAR ?= tar

and with portable make, we can of course still default TAR to tar in
  : ${TAR=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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]