[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: [PATCH] change default --format from gnu to posix
Date: Mon, 13 Dec 2021 01:19:16 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

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.

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:


(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:


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

reply via email to

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