bug#73316: Numeric user ID too large when generating the tarball

[Karl Berry]

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