[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'tar' in the GNU Coding Standards

From: Dr. David Kirkby
Subject: Re: 'tar' in the GNU Coding Standards
Date: Sun, 01 Nov 2009 21:38:51 +0000
User-agent: Thunderbird (X11/20090323)

Ralf Wildenhues wrote:
Hello David,

sorry about the delay.

* Dr. David Kirkby wrote on Sat, Oct 24, 2009 at 04:35:36PM CEST:
The configure script and the Makefile rules for building and
installation should not use any utilities directly except these:

     awk cat cmp cp diff echo egrep expr false grep install-info
     ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch tr true


I believe 'tar' should removed from that list, but allow someone to
select a variable for 'tar'. On Solaris for instance, Sun's tar can
not extract all tar files programs written with GNU tar, though it
does manage most of them. (It's not simply the fact some options
just as z and j are not supported, but more fundamental issues.

I agree that there are problems with non-portable tarballs.  That brings
up a couple of points:

The best way IMHO would be for GNU tar to default to a more portable format rather than its own 'standard'.

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.

The typical user downloading a tarball from the net and extracting it
does not use the $(TAR) in the makefile inside the tarball; he uses tar
on the command line, before the makefile is used for the first time, and
he doesn't need `make dist' or similar which would use tar again from
within the makefile.

If tar is not sufficient to extract some package tarball, then this
ought to be clear from the installation instructions.  However,
requiring, say, GNU tar in general, would be quite some move; we don't
usually any other GNU tools to be preinstalled, if only for
bootstrapping reasons.

A much easier move would be to get GNU tar to write by default in a more portable format.

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.

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 unsure of how wide-spread installation of a more capable tar program
is on systems with a limited vendor tar.

Issues with non-GNU versions of tar are common on lots of non-linux
platforms when using GNU tools.

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?

I haven't
yet seen a good Autoconf test for a capable tar, besides one that
wouldn't select GNU tar only; writing such a macro would probably be a
good thing to do before changing GCS.  Requiring the user to select a
tar program manually seems a bit awkward.  Note that one alternative to
choosing a tar program is to use something like the `missing' program
that Automake selects for some tools that may not be present.  OTOH I
don't see how packages can ignore or replace tar's functionality in that
case, unlike, say, makeinfo, where the info files are typically
distributed in the tarball.

Jöerg Schilling's 'star' is one other implementation I am aware of. He seems to have the knack of writing extremely portable code.

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?



reply via email to

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