Hi,
Turns out that change in tar is probably where this all started to go wrong.
[in pre-stretch, I think manifests were quoted and there were no files
starting -]
In stretch (pristine-tar 1.38; tar 1.29), manifests were quoted, and
extraction was done with tar --verbatim-files-from (that change was a
fix for #851286). This worked, because --verbatim-files-from unquoted
for you, and so in stretch there was a tar -t output that could be fed
back to tar reliably (via tar --verbatim-files-from)
Then tar made this change between 1.29 and 1.30:
"
2017-11-09 Sergey Poznyakoff <g...@gnu.org.ua>
Fix --verbatim-files-from
* src/names.c (read_next_name): Don't unquote name read from the
file, if --verbatim-files-from option is in effect.
(names_options): improve description of --verbatim-files-from
* tests/T-null2.at: Test the change.
"
Unfortunately, this meant there was no longer a round-trip possible from
any tar -t output to tar -T (as I noted previously in this bug report).
The tar authors presumably didn't notice this, but it was a big breaking
change.
This fallout was reported as #902115 against pristine-tar 1.44 - the
problem was in fact that tar --verbatim-files-from was no longer
unquoting the manifest; alas we missed this fact at the time and
pristine-tar 1.46 (buster) introduced the erroneous fix and started to
store unquoted manifests (and also unquote the contents of those
manifests a second time in some cases, which is definitely wrong).
Separately, the reporting and fixing of 933031 again missed the
underlying problem, and instead essentially went "if extraction with
--verbatim-files-from fails, try without that option as well"; while git
bisect picked up the fix to #851286 as the cause of the bug, this was
really incorrect - it was the underlying change in tar's behaviour that
was at fault. That went into pristine-tar 1.49 (bullseye)
[I'm not sure what sort of backwards-compatibility guarantees
pristine-tar makes?]
Regards,
Matthew
