Re: [PATCH] change default --format from gnu to posix

[Paul Eggert]

On 12/11/21 20:21, Mike Frysinger wrote:

> the warning is issued when DEFAULT_ARCHIVE_FORMAT
> has not been set by the builder, so the default value is used.  if the builder
> has set a value, then no warning is shown. 

Sorry, I must have got the code backward when I read it.


> i guess i could start putting "tar-pax" into my automake-bsaed projects.
> -mike

Something like that might be worth trying, for packages not intended to 
be widely portable. However, please bear in mind that the Automake 
manual cautions against using tar-pax, saying that tar-pax:

"... should probably be restricted to packages that target only very 
modern platforms. As of 2018, this format is supported by the native tar 
command only on GNU, FreeBSD, and OpenBSD systems; it is not supported 
by the native tar command on NetBSD, AIX, HP-UX, or Solaris."[1]

The Autoconf manual does say that 'tar-ustar' is reasonably portable, so 
that would be a better choice for portable distributions. Since ustar 
format is a proper subset of pax format, you would be generating 
pax-format tarballs if you specify 'tar-ustar', so there's that.


As I understand it, one disadvantage of 'tar-pax' is that it puts atime 
and ctime into the tarball, which will make it hard to build tarballs in 
a reproducible way. Also, it puts nanoscond-resolution timestamps into 
the tarball, which could make for some interoperability problems with 
systems like Git that don't support these timestamps. No doubt these 
problems could be worked around, if someone has the time to investigate 
and fix these problems. Still...


After looking into the above I decided to take the plunge and have 
proposed that the IANA tzdb distribution procedure use ustar rather than 
gnu format. See:

https://mm.icann.org/pipermail/tz/2021-December/031128.html

(I expect pax format would have been a bridge too far.)

After doing this I noticed an issue: GNU tar 1.34 puts "0" into the 
major and minor device numbers of regular files in ustar format, whereas 
it leaves them empty in the default gnu format. This appears to have 
been an accident of coding, so I fixed it here:

https://git.savannah.gnu.org/cgit/tar.git/commit/?id=738de9ecdec45ebfeb999628742373b5f8253bd0

and we can expect to see this change in the next 'tar' release (and I'll 
use the next 'tar' release, or some approximation, to generate tzdb 
tarballs so that tzdb users need not worry about this glitch). Evidently 
so few GNU tar users employ ustar and pax formats (the latter has the 
same problem) that nobody has noticed this little glitch until now. 
Although the glitch definitely shouldn't affect extraction, there are a 
lot of weird programs that read these tarballs and so this change is not 
necessarily trouble-free.

If the goal is to move GNU tar to generate ustar or pax format by 
default, none of these problems are insuperable; we can eventually get 
people to read the tarballs. But if the goal is to generate tarballs 
that are widely useful without trouble, I'm not so sure that defaulting 
to pax format would be a win.

[1] 
https://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html#tar_002dformats