Re: default tar format for "make dist" and patch file length

["Ludovic Courtès" <ludo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Reading the Automake manual (info (automake) List of Automake options) I
> stumbled on this:
>
>     ‘filename-length-max=99’
>          Abort if file names longer than 99 characters are found during
>          ‘make dist’.  Such long file names are generally considered not to
>          be portable in tarballs.  See the ‘tar-v7’ and ‘tar-ustar’ options
>          below.  This option should be used in the top-level ‘Makefile.am’
>          or as an argument of ‘AM_INIT_AUTOMAKE’ in ‘configure.ac’; it will
>          be ignored otherwise.  It will also be ignored in sub-packages of
>          nested packages (*note Subpackages::).
>
> This makes me think that Automake is simply configured out of the box to
> keep the file names as portable as possible (it doesn't mean it uses
> tar-v7 itself, IIUC, though I haven't checked).

Oh, looks like we could add the ‘tar-ustar’ option and be done with it
(info "(automake) List of Automake options"):

     ‘tar-ustar’ selects the ustar format defined by POSIX 1003.1-1988.
     This format is old enough to be portable: As of 2018, it is
     supported by the native ‘tar’ command on GNU, FreeBSD, NetBSD,
     OpenBSD, AIX, HP-UX, and Solaris, at least.  It fully supports
     empty directories.  It can store file names with up to 256
     characters, provided that the file name can be split at directory
     separator in two parts, first of them being at most 155 bytes long.
     So, in most cases the maximum file name length will be shorter than
     256 characters.

Any objections against the patch below?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 448 bytes --]

diff --git a/configure.ac b/configure.ac
index 84592f6041..341cff8fbd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_INIT([GNU Guix],
   [https://www.gnu.org/software/guix/])
 AC_CONFIG_AUX_DIR([build-aux])
 
-AM_INIT_AUTOMAKE([1.14 gnu silent-rules subdir-objects \
+AM_INIT_AUTOMAKE([1.14 gnu tar-ustar silent-rules subdir-objects \
  color-tests parallel-tests -Woverride -Wno-portability])
 
 # Enable silent rules by default.

[-- Attachment #3: Type: text/plain, Size: 1735 bytes --]


I tried it and there’s no tar warning and the file looks just fine,
including the long file names:

--8<---------------cut here---------------start------------->8---
$ make dist -j5
[…]
make[2]: Leaving directory '/home/ludo/src/guix'
tardir=guix-1.3.0.8612-7cad44-dirty && tar --format=ustar -chf - "$tardir" | eval GZIP= gzip --best -c >guix-1.3.0.8612-7cad44-dirty.tar.gz
make[1]: Leaving directory '/home/ludo/src/guix'
if test -d "guix-1.3.0.8612-7cad44-dirty"; then find "guix-1.3.0.8612-7cad44-dirty" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "guix-1.3.0.8612-7cad44-dirty" || { sleep 5 && rm -rf "guix-1.3.0.8612-7cad44-dirty"; }; else :; fi
$ tar tvf guix-1.3.0.8612-7cad44-dirty.tar.gz |grep patches/xplanet
-rw-r--r-- ludo/users     1252 2020-04-06 00:14 guix-1.3.0.8612-7cad44-dirty/gnu/packages/patches/xplanet-1.3.1-libimage_gif.c.patch
-rw-r--r-- ludo/users      765 2020-04-06 00:14 guix-1.3.0.8612-7cad44-dirty/gnu/packages/patches/xplanet-1.3.1-xpUtil-Add2017LeapSecond.cpp.patch
-rw-r--r-- ludo/users     6990 2020-04-06 00:14 guix-1.3.0.8612-7cad44-dirty/gnu/packages/patches/xplanet-1.3.1-cxx11-eof.patch
-rw-r--r-- ludo/users      783 2020-04-06 00:14 guix-1.3.0.8612-7cad44-dirty/gnu/packages/patches/xplanet-1.3.1-libdisplay_DisplayOutput.cpp.patch
--8<---------------cut here---------------end--------------->8---

> Seems a good thing to be as portable as can be, especially since 200
> chars patch file names wouldn't look good in the sources anyway ;-).

I don’t think we care about “portability” as understood in the context
of Automake, which roughly translates to “support SunOS 2 and HP-UX’s
1991 ‘tar’ implementation”.  :-)

Thanks,
Ludo’.