When running "make dist", guix apparently uses a very old tar format
(presumably for maximal compatibility with tar implementations), which
has a hard limit of 99 characters.

For this reason, there is a guix lint check for filename lengths, but
there are quite a few lint warnings in guix master and
core-updates-frozen.

On guix master db5907138cbf9139e885fa4b3860d604aff0be9c, there appear to
be 14 such patches:

$ guix lint --checkers=patch-file-names | grep 'too long' | nl

     1  gnu/packages/admin.scm:2669:2: debops@1.1.0:
     debops-constants-for-external-program-names.patch: file name is too
     long
     2  gnu/packages/astronomy.scm:865:2: xplanet@1.3.1:
     xplanet-1.3.1-libdisplay_DisplayOutput.cpp.patch: file name is too
     long
     3  gnu/packages/astronomy.scm:865:2: xplanet@1.3.1:
     xplanet-1.3.1-xpUtil-Add2017LeapSecond.cpp.patch: file name is too
     long
     4  gnu/packages/geo.scm:312:2: libgeotiff@1.5.1:
     libgeotiff-adapt-test-script-for-proj-6.2.patch: file name is too
     long
     5  gnu/packages/glib.scm:478:2: gobject-introspection@1.62.0:
     gobject-introspection-absolute-shlib-path.patch: file name is too
     long
     6  gnu/packages/java.scm:9032:2:
     java-tunnelvisionlabs-antlr4-runtime@4.7.4:
     java-tunnelvisionlabs-antlr-code-too-large.patch: file
 name is too long
     7  gnu/packages/java.scm:8926:2:
     java-tunnelvisionlabs-antlr4-runtime-annotations@4.7.4:
     java-tunnelvisionlabs-antlr-code-too-large
.patch: file name is too long
     8  gnu/packages/java.scm:13120:2: java-apache-ivy@2.4.0:
     java-apache-ivy-port-to-latest-bouncycastle.patch: file name is too
     long
     9  gnu/packages/java.scm:9040:2:
     java-tunnelvisionlabs-antlr4@4.7.4:
     java-tunnelvisionlabs-antlr-code-too-large.patch: file name is
 too long
    10  gnu/packages/kde-frameworks.scm:3419:2: plasma-framework@5.70.1:
     plasma-framework-fix-KF5PlasmaMacros.cmake.patch: file name is
too long
    11  gnu/packages/llvm.scm:98:2: clang-runtime@3.9.1:
     clang-runtime-3.9-libsanitizer-mode-field.patch: file name is too
     long
    12  gnu/packages/llvm.scm:852:4: clang-runtime@3.5.2:
     clang-runtime-3.5-libsanitizer-mode-field.patch: file name is too
     long
    13  gnu/packages/llvm.scm:98:2: clang-runtime@3.7.1:
     clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too
     long
    14  gnu/packages/llvm.scm:98:2: clang-runtime@3.8.1:
     clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long

Looks like a similar number of patches on core-updates-frozen, too,
probably mostly the same ones.

Luckily, the lint check is conservative and actually gives a bit of
wiggle-room, and none of these appear to break "make dist" from
generating a tarball at the moment, but there was one in
core-updates-frozen recently that did break "make dist" (fixed in
6cdf4e5bf230fdbe17e592c2ec74fb34dba70eb5).


Ideally, "guix lint" would be run and issues fixed before applying
patches ... !

Is it worth adding an inexpensive check to etc/git/pre-push that also
checks for file-length and fails to push due to this issue potentially
breaking "make dist"?


A different angle might be to actually use a different tar format:

  https://www.gnu.org/software/tar/manual/html_section/Formats.html

I would guess "make dist" is using the tar "v7" format, based on the 99
character length limit for files. Most of the other formats have no file
length limit or a longer limit.


Well, thanks for following my rambling this far!


live well,
  vagrant