Paul Eggert <egg...@cs.ucla.edu> writes: > On 2025-01-29 11:20, Simon Josefsson via Gnulib discussion list wrote: >> It seems tar 1.13.25 from Debian 3 doesn't understand the virtual >> ./PaxHeaders/ sub-directory and print warnings. It still exits >> successfully though. But it create a ./PaxHeaders/ sub-directory in the >> current directory. This breaks some workflows that assume that the >> first directory entry of a release tarball is the sub-directory to cd >> into and start the build process. > > Oh, I hadn't run into that one. > > To fix, you can replace this: > > cd $(tar tfz tar/b-trisquel11/libtasn1-*.tar.gz | head -n1) > > with this: > > cd $(tar tfz tar/b-trisquel11/libtasn1-*.tar.gz | grep -v > '^\./PaxHeaders/' | head -n1)
Right, this could equally be regarded as a bug in my scripts, that could be fixed like that. However my current thinking is that I don't want release archives to have any /PaxHeaders/ sub-directories at all. I don't see what information is useful in a software release tarball that needs to go in there? I'm not sure if it makes sense to use --format=posix and make an effort to remove all metadata information that trigger tar to create */PaxHeaders/, is there? > Admittedly it's yet one more pain for tar reproducibility+portability. Would it make sense for tar to put its PaxHeaders sub-directory last in the tar archive? Or at least just after the particular entry that is being worked on? I suspect that this may be difficult; I assume tar read things sequentially and use the PaxHeaders data when acting on subsequent data. /Simon
signature.asc
Description: PGP signature
