Hi, Quoting Paul Eggert (2026-10-24 21:45:23) > On 2026-10-24 02:11, Johannes Schauer Marin Rodrigues wrote: > > I wonder if it would be > > possible to either: > > > > 1. not include the PID in the output by default or > > 2. to add a command line flag which to suppress inclusion of the PID > > Either might be a bit much, as I expect other tools expect a PID there now. > But we could hardcode it to be PID 0,
Yes, that's what libarchive does: https://sources.debian.org/src/libarchive/3.8.9-1/libarchive/archive_write_set_format_pax.c?pow_referer=#L1909 > or something like that. That might be the simplest solution if you insist on > --format=pax. Or add a command line option which forces a PID of 0 to be used instead of the current %p. Or something I just came up with: if the $SOURCE_DATE_EPOCH environment variable is set, then that is the user communicating that they want the software they are running (tar in this case) to produce bit-by-bit identical output. GNU tar could, like other software, use the value of $SOURCE_DATE_EPOCH (if it is set) where currently %p is used. That way, you can retain the current behaviour (which other tools expect) while at the same time catering for those who want their software to behave in a bit-by-bit reproducible manner. Those who do, will have $SOURCE_DATE_EPOCH set in their environment. > In the meantime a simple workaround is to use --format=gnu, no? But --format=gnu can not have GNU/Hurd translators, nor extended attributes nor ACLs or subsecond precision, no? I found this bug while working on my tool mmdebstrap which creates chroots for Debian and its derivatives and those chroots rely on extended attributes or otherwise many modern desktop OSes will start doing weird things. Thanks! cheers, josch
signature.asc
Description: signature
