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