Hi Giacomo - thanks for the report. Unfortunately, I (still) don't see a good way for Automake can automatically deal with this problem. After reading the various links in your message, it seems even less feasible.
Automatically switching to tar-pax if the current id is too large feels like too big of a change to me. The user might well want to fix it in another way. I know I would. Does tar report an error for you with a too-large-for-v7 uid value? I get, e.g., $ tar -cf x.tar --owner=31863269 --format=v7 x.html tar: value 31863269 out of uid_t range 0..2097151 tar: Exiting with failure status due to previous errors So I don't see anything to be gained by automake trying to detect the situation just to issue a different error. All I can see to do is to add tar-pax as another workaround for the problem in the manual. (Glad you had that idea.) * Regarding "privileges" needed for --owner=0 --group=0, as you reported in https://savannah.gnu.org/bugs/?65578#comment5 ... that seems strange. It's just writing a file with certain bits. It does not happen for me with GNU tar 1.34 (compiled from the original source). But given that that was the case for you, that's another argument for automake not to try to do anything automatically. For instance, you could (hopefully) use --owner=1 --group=1 instead, if your tar somehow does something special about [ug]id 0. * Regarding the TAR_OPTIONS envvar, it works for me with the same tar 1.34: $ TAR_OPTIONS=-v tar cf test.tar test.txt test.txt So I don't know why it didn't work for you. Puzzling. Happy hacking, Karl
