Pádraig Brady wrote:
Anyway the general point of this thread is that
fixing this with options to each generator of xz is not practical.
Either the default xz crc should be changed to crc32,
or more likely busybox xz would gain crc64 support.
Xz-utils and busybox are not the only xz implementations. Asking each xz
implementation to standardize on the same check type is as unpractical
as changing the options passed to each generator of xz files.
Is there any chance to fix the problem once and for all by switching to
lzip (as Eric Blake proposed[1]), instead of asking others to just
palliate some of the symptoms?
[1] http://lists.gnu.org/archive/html/coreutils/2017-01/msg00008.html
Err, busybox supplies xz...
Sure. But my point was if you're compiling on this system,
a crc64 capable xz shouldn't be too hard to obtain.
Not everybody decompressing a tarball does it to compile its contents.
They may simply want to browse the code, or to extract a function to use
it in their small system. Asking users to obtain a crc64 capable xz, or
to use an intermediate system to extract and checksum the data, is not
reasonable. Switching to lzip solves all these silly complications with
check types and options.
Best regards,
Antonio.
